Transport Request copy between systems

[former_member217571]

Currently we have a ERP landscape consist of DEV/QAS/PRD and there's another ERP system separately copied in the past for reference purpose.

Days ago, we required to create a new transport request in the reference system and copy it to a current developement system. Hence, I manually access the file system and copied relevant datafile and cofile of the transport request. However, when I add this TR into the current development system, I realized that the same no. of request w/ different objects and description was already created and released. For that reason, even if I added the new transport request in DEV in STMS, the system still recognize it as the one which is released previously.

Is there any ways that I can do to avoid such problem?

[Matt_Fraser · Accepted solution]

Hello Seong,

Your reference system should not have the same SID as the original system it was copied from. This is the source of the problem. You may need to go back and recreate the reference system, this time choosing a unique SID for it, or run it through the System Rename process in SWPM. Then transports created from it will have unique IDs.

Another recommendation, if you anticipate regularly moving transports back and forth, is to add it to your same transport domain as the original system. This way you will not need to manually copy the files between servers. Instead, all files will be kept in the same location on the central transport host (typically your transport domain controller, and frequently your DEV system), and so adding the transport to any given system's import queue can be done from within STMS.

But you have to solve the non-unique SID issue first.

Cheers,

Matt

[former_member217571 · Accepted solution]

Thanks for the advice. Now I clearly understood the problem.

Unfortunately, it will take a few more days until I can get a basis support so now I'm looking for a workaround I can take. One possible option that I'm thinking now is, using a CTS no. which was created in DEV but not released and finally deleted.

I just compared both Reference and Development systems and found one candidate no. Do you think this idea is applicable? Or it is still not valid even though it was previously deleted and not released?

[Reagan]

Like Matt said, if there are multiple systems with the same SID then you will get this issue. The table E070L holds the last transport request number and based on this the new transport request number is generated. The best solution is to changed the SID of the reference system through system copy. The other option is to change the number range in the reference system table E070L but there is a strong possibility that you will face this issue some time in the future based on the amount of transport requests generated. Check the SAP KBA 2235335 - Duplicated transport requests in the import queue Having multiple systems with same SID is not supported. This is clearly mentioned in the installation guide as well. Having two systems with the same SID is not a big concern but it makes me wonder why a request from the reference system should go into the development system. It should be the other way round, isn't it?

[former_member217571]

It's a bit complicated but simply explain, there's several programs created in this reference system but not in Dev system. I have a need of them in the DEV system as well. However, as its scale is a bit huge and related to several programs, a developer said he cannot make the same ones just copy and paste of the source codes and configuration changes in short time but it will take days.

[Matt_Fraser]

If it is just ABAP programs, you should be able to export the source code to a file, then import the same source code from that file into the DEV system via the ABAP Workbench (SE38 or SE80). However, if there's more to the development, such as data type definitions, table definitions, and so forth, it could get more complex. It could be done, but then yes, it might be easier to use a transport. In this case, Reagan's method might be the best workaround, where you can manipulate the transport number range in both systems so you can guarantee a unique number.

[former_member217571]

Problem resolved Thanks!