Reg: Transporting deleted entry to other client

[Former Member]

Hi,

We have included entry in the table T77UA and transported the same entry to other client.

Now the same entry has to be deleted in both the clients.

How could we delete the entry and make the deletion reflect in other client through transport.

Regards,

[Former Member]

delete the entry in the originating client and transport the table.

Alternatively do what most people do and edit it in each client via tx OOSB

[sdipanjan]

Please note that the changes to Table directly is not a recommended approach as it may arise data redundancy. All tables are linked with TCodes to update their contents. Please let us know what exactly you want to delete here so that we can suggest you a better process.

regards,

Dipanjan

[Former Member]

In this case OOSB is just a maintenance dialog for T77UA via SM30

[Former Member]

Hi,

Thanks for your inputs.

I just need to delete a structural profile assignment from a client which has its status as Test system

We have been doing assignments in a productive client and transporting the changes to the test client.

We have been doing the assignemnts through table T77UA (Trx OOSB)

But now the scenario is deletion.

Now i have added the entry in transport, deleted the entry from the table T77UA.

And transported to the other client.

The profile assignement has been deleted.

Is there any other best practice for doing this ?

Regards,

[Former Member]

Typically you maintain OOSB in the target client. This is common practice which is fine if performed with adequate control. If you are directly maintaining the link in your prod system then there is no problem doing the same in your on-prod systems. No need to transport from prod.

Obviously if you have sensitive "real" data in your test system you should have a policy which dictates who can have access etc and any assignments should follow the relevant approvals.

[Former Member]

An important aspect of the TMS is to keep the config in sync, however you have to do the maintenance somewhere in the source.

As "best practice" I would only say that you should not mix the two at the same time, and for some tables transports should be avoided as you might end up with duplicate entries.

I would class T77UA as application data. My opinion on a good practice for this from Prod to Test would be to use either a client copy of an appropriate profile or a temporarily activated eCatt from the TEST system to extract the data. This way you can control the validity of the connection "from below", or ideally via the validity of the user in PROD "from above" without having to fiddle around in SM59 or STMS connections.

My 2 cents,

Julius

[Former Member]

Hi,

Thanks for your replies.

Regards,