1. error messages about logs not being found during the transport.
This is usually caused by incorrect maintenance of the setting for the transport directory. Check particularly the parameters DIR_TRANS and TRANSDIR by referring to the advice given in note 556734, section "What do I need to consider when setting up the transport?".
2. The system reports a DB connect problem! What can I do?
For the test and as a basis for a further analysis, the command "R3trans -d " or "R3trans -x " can be used as user <SID>adm. A file trans.log is then also written in addition to the message via the return code of the attempt in the current directory. In the case of a connection problem, this contains details on the error message. R3trans mainly checks environment and database configuration files. If no error is found here, the parameters can also be checked from the transport profile with the call "tp connect <SID> pf=DIR_TRANS/bin/<transport profile>" (use backslashes with NT). The connection test can also be carried out from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL). There are also additional notes on the respective database systems:
DB2: 152929, 83255, 136806
DB4: 515447, 67213, 69429
DB6: 80292, 53141, 167361
Informix: 85404, 112184
Microsoft SQL Server: 351586, 128126, 116735
Oracle: 193616, 400241, 403004, 134447, 443867, 445029, 437362, 505630
SAP DB: 39439
These notes do not apply to everything! They mostly only apply to certain R/3 or database releases. Only use the relevant notes that apply in each case!
3. When I create transport requests, they are always local!
Check in the TMS at the domain controller whether the transport routes are there. Usually the development system is the source system (the objects are created/changed there). From there, there are consolidation routes into one or several systems that can also be virtual. The consolidation route with transport layer SAP is intended for repairs to SAP objects. With customer transport layers for customer objects, the object must have a development class which is assigned to this transport layer. The corresponding development class can be displayed via transaction SE80.
4. The tp does not write requests to buffers of the subsequent system.
Check whether the transport routes are generally set up and fully activated and distributed. If it only concerns certain transports, check whether these are Workbench or Customizing requests or special transports (transport of copies/relocation). In particular with system copies and restores with incomplete recovery, you must be aware that afterwards the status of the buffer and the database may no longer agree. (For example, you import request C11K901234 into the consolidation system Q11 and then it is displayed in the Q11 buffer that the request is already imported in Q11. The request is not imported into the P11 system. Now you make a system copy from P11 to Q11. Now the request C11K901234 is not contained in Q11 (in SAP), however according to buffer Q11 it is imported).
5. An import seems to hang.
Check in the directory DIR_TRANS subdirectory tmp whether the import process regularly updates a log file for a certain import phase. The last entries in this log file provide information about what the import process is currently doing.
If the import hangs, you may find more error messages in the directory DIR_TRANS subdirectory log in the file SLOG<YY><WW>.<SID> (YY are the last 2 numbers of the year and WW is the calendar week). The lines at the end of the file often even contain detailed messages on the error, such as RDDIMPDP is not scheduled. The following notes should also be checked: 12746, 71353, 26966, 449270.
If no helpful information has been found in the SLOG, you should check in DIR_TRANS subdirectory tmp whether there is a file there with extension .LO and this should be compared with note 12746. You can also check the tables TRBAT and TRJOB via SE16 or SM30 to see if there are old entries there.
6. Not all clients contain client-specific entries!
For objects that enter the system via ADO or SDO import, you must check whether the corresponding jobs RDDIMPDP_CLIENTnnn were released here with the corresponding authorizations. With transports that are to be imported into several clients of a system, you must check whether you worked here with the correct unconditional modes in each case (the first import must be imported with U0 and the following one in each case with U1). Also, a further point which must be considered is the table delivery class belonging to the table. This controls which entries are imported with the various transports into which clients. You will find further information on this in note 2857.
7. An import supposedly has an error, but I cannot find an error in the log files.
This is usually due to the order-independent logs. In the order-independent steps, DDIC objects of other requests may also be edited. For example, the request to adjust a table remains for so long in the internal transport tables and is therefore also processed during a subsequent transport until the adjustment was successfully completed. An error can then be displayed for the subsequent request although its objects were all imported without any errors. Explanatory notes for this are 413993, 512493, 407116 and 330378. After every import, the order-independent logs should therefore also be checked.
If the system refers to canceled RDD* jobs, check the job log via SM37 and via ST22 the short dumps and via SM21 the syslog of the system.
8. A certain program has syntax errors after a transport into a non-development system.
Check whether the syntax errors also occur in the development system. If this is not the case, compare the versions of the program and of the function modules used by the program with the versions in the development system. Different versions can arise if corrections were not yet transported further in the development system or if the sequence of the import does not correspond to the sequence of the export. To solve the problem, import the last changes from the development system into the subsequent system as well.
9: The status in the TMS is "Import runs" although it is already finished or canceled.
In transaction STMS -> OVERVIEW -> IMPORTS we can reach, by double-clicking, the import queue of the corresponding system.
Click on Goto -> Import Monitor, Now we can see the status of both individual imports and Import all or Import subset.
If the tp has already been started, you also see the tp process ID here and you can check at the operating system level whether the process still exists
(for example ps -ef | grep tp or via the Windows Task Manager). If the tp process still exists, execute the checks for hanging transport