SAP Note 28324 - R3trans: Composite note "duplicate key" array insert

Symptom:

Caution: This is a composite note. It describes only one symptom which can have many different causes. It is therefore not advisable to give this note to a customer "just in case". More precisely, the problem must be analyzed, so it has to be clear which of the causes described below applies.

R3trans terminates during the import due to a "duplicate key" on array-insert.
This termination can be recognized as of Release 2.1G by the following messages at the end of the log:
2EETW150 sap_dext called with msgnr "900":
2EETW000 Internal error in DB interface
2EETW000 ---- db call info ----
2EETW000 function: db_xrtab (or db_rtab)
2EETW000 fcode: RT_MI_END
2EETW000 tabname:
2EETW000 keylen: ...
2EETW000 key: ...
4 ETW000
4 ETW000 ROLLBACK (...).
(The function code RT_MI_END represents the writing out of the entries gathered in the database. The key included in the log is the last one written. However, it is not necessarily the entry which caused the error.)

If the table in which the error occurs is not a transparent table (that is, with corresponding DB table), but a pool or cluster table, the duplicate key error can also occur.
Here, however, there is no termination of R3trans, but only error messages such as:
2EETW000 Duplicate Key error during insert into table ... occured
The first two of the causes listed below do not apply to non- transparent tables. The first two causes listed below deal with incorrect index definitions.

Cause and prerequisites

The error can have different causes.

1. Several UNIQUE indexes are defined on the table.

• The most frequent cause of "duplicate Key" errrors during import are unique indexes which are defined in addition to the primary index (index over the key fields). You can find out with the data dictionary (SE11) wether such indexes are defined (the primary index is always defined and will not be diplayed by the data dictionary).

• Dependent from the data contents, R3trans is sometimes not able to handle such indexes. R3trans tries to merge the existing table entries with the to be imported ones and to write back only the changed entries. This may fail with such indexes depending on the table contents.
  Up to now, this error was observed for the following tables:
  COFIO1 GLPCA GLPCC GLPCO
  Solution: remove the table entries manually (with an ABAP program or native tools like sqlplus, dbaccess, ...) in the target client.
  This problem is solved as of R3trans release 3.1I.

• In some cases the cause of the "duplicate key" error is a unique index which is not defined correctly.
  Up to now, this error was observed for the following tables:
  PROJ, PRPS, see note 16095.
  CABN, MAPR, see note 5625.
  Solution: Create the index as non-unique index or add the field MANDT to the index.

2. Missing primary index.

• The primary index is missing in the source system. It is thus possible that entries were inserted in a table with the same key.
  If the primary index is created in the target system, the error occurs during the import.
  The primary index of a table is generally created immediately when creating the table. If it is missing, the author either overlooked an error when creating the table, or the index was the victim of an incorrect reorganization.
  Up to now, this error was observed only for the following tables (all in 3.0):
  CDMMT COSRV KONV M_MBANP T622 WLK1

• Solution: Clean up the table in the source system (remove duplicates), create the index and repeat the export.

3. Different structure.

• The table is different in the source and target systems with respect to the key structure. At least one key field is missing in the target system. As a result, entries which are unique in the source system are duplicated in the target system.
  In this case, the following warning is found in the import log:
  3WETW000 different nametabs for table (field ).
  4 ETW000 Field is not in NTAB.

• Solution: Adjust the table and repeat the import.

4. Language-dependent tables with meaningless values in the language field.

• For language-dependent tables which have the language field at the end of the key and have language entries which do not occur in the R3trans default language vector (esp. ' '), the import termination due to a duplicate key can also occur.

• This problem was solved in Release 2.1G/2.2A in that R3trans selects the languages later. Thus, the error can only occur if the export was created with a R3trans <= Release 2.1F.
  Up to Release 2.1F, the default language vector had the value DEFIJKNOSV.

• Up to now, this error was observed only in the following tables:
  CKHT KNVD MAKT SKAT STXH STXL T513U

• Solution, see Note 2666.

5. Several ABAP/4 Dictionary short texts are active in the source system.

• Due to a sporadically occurring error in the ABAP/4 Dictionary, the short text for tables, domains, data elements etc. can be stored more than once and the only difference for the entries is the internal version number. During import, R3trans always sets this internal version number to '0001'. This then causes duplicate entries.
  You can check whether this is the cause of the problem with Transaction SE17 (General table display) in the source system.

• The error can only occur in the following tables:
  DD01T DD02T DD03T DD04T DD06T DD07T DD08T DD12T DD20T DD23T DD25T

• Solution: Clean up the entries in the source system by reactivating the corresponding Dictionary object. Then repeat the export.

6. ORACLE database is installed incorrectly.

• It is possible that the ORACLE DB system is installed incorrectly with regard to the national language support (nls). R3 databases must run with AMERICAN_AMERICA.US7ASCII. Otherwise, R3trans has difficulties if entries are required in a sorted sequence, but are not actually sorted (for example, with a binary search).
  Up to now, this error was observed only in the following tables:
  D021T, see Note 5625.

• Solution: Set the variable NLS_LANG = AMERICAN_AMERICA.US7ASCI. See Note 8760; This error is quite rare and has other symptoms (for example, umlauts displayed incorrectly).

7. Preceding deletion did not work.

• R3trans always uses array-insert if it can assume that none of the entries to be imported already exist. This is also the case, for example, if they were just deleted by R3trans. If no entries were deleted due to an internal error in the deletion, the termination can occur.

• In Releases 2.1 and 2.2, the termination can be caused by an incorrect WHERE condition for DELETE. This error is corrected as of 2.1M/2.2G by converting the deletions to another database interface function.

• Up to now, this error was only observed in the following tables:
  FINS M_CLASE RFDT T130F T52A0 T582S T804C T811I TCM4 TTXID TTXIT TVDIR
  TWFDB

• Solutions and details for the problem, see Note 7100.

8. Preceding deletion was incorrect due to keys with different structures

• The deletion of entries can fail because the structure of the table in the key was changed.

• Cause: R3trans saves the key(s) to be deleted as a generic string, but the string is not converted if the structure is different.

• Result: Deletion uses an incorrect string, which usually does not delete enough entries.

• Solution: First transport the modified structure and then the corresponding entries.

9. Incorrect decision for array insert after a previous deletion of a similar table entry

• In certain circumstances R3trans can incorrectly assume that a table entry about to be imported has just been deleted, and can therefore be imported with array insert. The following conditions must all be fulfilled:

• Two entries from the same table must be selected directly after each other in the transport request.

• The first of the two selections contains a completely specified key: that is, not a generic with *.

• The first selection is shorter than the second, but is, at the same time, a partial string.

• Example: two entries are selected from table T51TF with the following keys:
  011E10HR_F_UNEMP
  011E10HR_R_UNEMP_CA

• Result: the keys are not compared long enough and it is incorrectly decided that the entries of the second selection can be imported per array insert. When they already exist, however, an error occurs.

• So far the error has been observed only for table T51T7.

• Solution: transport the first entry generically (*). Error corrected in Release 3.0D.

10. Incorrect merging of table entries with long keys (> 50 Bytes) when transport with R3TR VDAT

• The error comes up as of Release 3.0C and was solved with Release 3.1I.

• The cause and a workaround are described in Note 65887.

11. Incorrect import of language-dependent tables

• In Releases 3.0FCS - 3.0C, the duplicate key error can occur when transporting entries from language-dependent tables, if the following conditions are met:

• a specific language is explicitly given in the key entry
  - when exporting this transport request, a language vector is used which does not contain this language (in TPPARAM),
  in addition, these keys already exist in the target system.

• Since in a normal customer installation there is no explicit language vector given in TPPARAM; the error practically does not occur in customer systems.

• So far, this error has only been observed in table T241H.

• Solution: In TPPARAM, expand the language vector to include the languages selected in the transport request and repeat the export.
  In Release 3.0D the error is corrected.
  

12. Other problems during preceding deletion.

• It is theoretically conceivable that R3trans has other deletion problems in 3.0. From the log it is possible to see how many table entries R3trans deleted previously, and with which key. With Transaction SE17 (or native tools, such as sqlplus, dbaccess ...), you can check whether this number is correct.
  If it is not, ask the author of this note for further information.

13. Subsequent errors after other SQL errors for array-insert.

• If other SQL errors (for example tablespace overflow) occur when using array-insert within R3trans, further insert attempts are mistakenly refused with the error "duplicate key".

• Solution: Correct the original error and repeat the import.

14. Export from all clients

• It is possible to enter the option "client=all" in the control file when using R3trans directly during the export. This exports from all clients for client-specific tables. If you now import into a certain client ("client=..."), or with "client cascade = yes", the termination can occur due to double entries.
  It should be clear from the logs whether these options were used.
  However, the option "client=all" is neither documented nor supported.

• Solution: Do not use "client=all" during the export.

15. Termination on insert in table DDPRS for logical R3trans backups

• The status information on every R3trans backup is internally logged by R3trans in table DDPRS. This causes a termination if several of these backups run in a system at the same time.

• Solution: Use organizational means to run these backups sequentially.
  The error is corrected in Release 3.0F.

16. Only with DBMS DB2/400 (operating system AS/400): tables with key fields of type 'P' (packed data).

• For packed data, several different but equivalent representations of the sign are possible. With DB2/400, this packed data is converted internally to a normalized representation. In this way, R3trans causes duplicates of table entries that differ only in the representation of the sign symbol.

• This problem occured only with table T5J40 so far.
  It may theoretically occur with the following tables:
  BSIP T440Y T5J14 T5J39 T5J40 T5J41 T5J42 T5J43 T5J44 T5J57 T5JA3 T5JC3 T5JC4 T5JSY T5JT1 T5JT2 T5JT2 T5JT3 T5JT3 T5LER T7NZTE

• Solution: solved with 3.0F.

17. For operating system DEC alphaosf only: Tables with key fields Type I (INTEGER) or S (SHORT).

• On DEC machines the internal representation of 2 and 4 byte integers doesn't always allow a bigger/smaller comparision with memcmp().

• So far this problem occured only with table CNTLSTREAM.

• Solution: solved with 3.1H.
  Duplicate key error with table SREPALOG
  Because of the different structures of table SREPALOG in Release 3.1 and 4.0 duplicate key errors can occur during the transport from 4.0 to 3.1.
  Solution: solved with Rel. 3.1 R3trans version from 12/11/98 or more recent.
  This corrected R3trans is provided on sapservX, path:
  ~ftp/general/R3server/patches/rel31I.

Solution
Depending on the cause, there are different solutions (see above). In all the above-mentioned cases, the import can also be carried out with the R3trans option safeandslow=yes. This is especially useful if there is no time for extensive error recovery.
This option forces R3trans not to use array-inserts, thus making the import secure, but slow. All table entries which cannot be inserted are logged in the file trans.dsc.

Additional key words

R3trans rt_mi_end array insert arrayinsert rc128 duplicate key in index