You are using transaction SCC9 to start a Remote Client Copy in the target client. (As a result, the target system is also called the local system in the following and the source system is called an RFC system.)
Here you must specify the copy profile (for more information, see the online documentation as well as note 24853) and the RFC destination.
The RFC destination must have been created beforehand using transaction SM59 (which can be accessed via the F4 input help). With this destination, you must be able to access the source client data in the background (that is, without a logon screen). There are two options for this:
Set up a Trusted System connection. For more detailed information on Trusted System connections, see note 128447, for example.
If you do not want to set up a Trusted System connection, the RFC destination must be created using both a user and its password in the source client. For security reasons, you should use a user with the user type "communication" in the source client.
If necessary, set up parallel processes (note 541311).
Depending on the status and size of the source database, you should increase the "rdisp/max_wprun_time" TIME-OUT parameter on the application servers of the source system. This may also be done temporarily using transaction RZ11. Display the parameter. You can change it afterwards. You do not have to restart the system for this.
You should also refer to note 489690, which contains information on copying large clients. In particular, it is recommended that you carry out a test run in advance (select the simulation type), to eliminate problems with PSAPTEMP or TIME_OUT in the source system, for example.
You can now start the client copy (we recommend that you schedule this in the background).
The process for the Remote Client Copy:
A Remote Client Copy works as follows:
a) Create a list of tables to be copied. The process here is the same as for a local copy (once in the source clients and once in the target clients in each case). For more information on selecting data, see notes 19574 and 24853.
b) Test the dictionary compatibility between the system.
The structure of all tables to be copied is examined. If only some of the data can be copied because, for example, tables are missing in the target system or fields are missing in the tables, the copy process is cancelled after the DDIC comparison. All table differences are recorded in the log. The Solution section deals with possible messages.
c) The data is now copied to the tables. For this, existing entries in the target system are deleted first and the data in the source system is then transferred in blocks to the target system.
d) Finally, corrections, local adjustments and generations are started automatically (reports and other objects are generated which, according to the Customizing, are required at runtime).
Solution
The client copy log notes errors and problems that occur (transaction SCC3).
The file log for the copy contains details that you can display from the log display. It is usually enough to open the log up to level 3 to analyze errors and warnings. Alternatively, you can expand the log completely and search for the name of the affected tables. You should also consider messages that immediately follow or precede as these often contain additional information.
For additional notes on analyzing problems with a client copy, see note 22514. However, note that important information is often only available in the SysLog (transaction SM21) of the source system.
1. Status "Cancel, Dictionary Differences."
The copy was cancelled due to different table definitions that result in only some of the data from the source system being transferred to the target client. Message TA 251 or TA 254 is displayed in the log:
TA251 & tables cannot be converted
TA254 Critical differences: Missing tables: &
The following messages appear in the file log (these caused the above message):
TA281 Length change
TA283 Table & is convertible to the RFC system, field missing locally
TA284 Table & is incompatible, the fields are incompatible
TA285 Table & is incompatible, fields are missing in both systems
TA287 Table & is only convertible from the local system to the RFC system
TA308 Table definition & missing in the target system
Clarify the cause of the differences between the systems. For this, the version management (transaction SE11) of the tables in the corresponding systems is the first indicator. From there, you can also compare the table structures with other systems via an RFC destination.
Upgrade the systems to the same development status.
It only makes sense in exceptional cases to exclude tables from the copy because changes to the table definitions are frequently linked to incompatible program changes. In each case, the customer always assumes responsibility for the consistency of the affected data. SAP cannot provide support for this, especially if it is a modified enhancement (ADD-ON), for example:
Individual tables may be excluded (note 70290 - with message TA308 in the source system, otherwise in the target system).
If many tables are affected, for example, because an add-on cannot be installed in the target system, the RSCC_PACKAGE report is available as of Basis Support Package SAPKB61026 or SAPKB62013. You can use this report to include complete development packages (formerly development classes) in an exception list in the source system. If a table is missing from these packages in the target system, this merely generates a message in the log and no longer causes a termination.
As a last option you also have the parameter NO_RFCCHK (see note 446485). This will always prevent termination and easily causes problems not to be identified. This parameter should therefore only be used as a last resort and only after an incoming check of all DDIC differences.
Tables, for example, for which a field was added in the source system is not copied but rather initialized in the target client. If the table definition cannot be adjusted, the data in these tables must be copied, if required, to the target system (using another path). To do this, you can, for example, use the Transport Organizer (transaction SE01) to create a "Transport of copies" in the source client with an "R3TR TABU