INT key transport problem

[former_member217157]

Having issue transporting tables with System/Customizing data because of INT4 as one of the primary keys in the tables.

Our data model has been ported from Oracle to ABAP DDIC. The tables with number(10) data type have been changed to INT4 domain. After the data model has been built and we were ready for transport, none of the System or Customizing data was captured because of transport limitation when it comes to Integer Keys. It woks only with NUMC data type.

We typically get an error:

Message TK319 , “Fill table key for table <table> only up to position 004 only”.

The only way to get around thi is to avoid this message in debug mode in FM: TR_REQ_CHECK_KEY line 429.

This issue with transport is not mentioned in any SAP ABAP development notes.Also there was no error / warning creating a S table with INT4 key.Since the issue has been recognized late in the game, it is expensive to change the datamodel.

Any suggestions on how to avoid this problem will be highly appreciated.

Thanks,

Raghav

[Former Member]

The entire key of any transportable table must be CHAR or NUMC. If you do not want to change the type definition of the table, every transport you make will transport the entire table (well <i>almost </i>the entire table). Why? Because the transport entry can only be of the form R3TR TABU *.

To be more specific, let's asume that your table has 3 key fields:

A. FLD1 is MANDT modeled after SY-MANDT.

B. FLD2 is Company code modeled after BUKRS.

C. FLD3 is custom Z field of type INT4.

In this case, you can only transport entries at the company code level. You transport key will look like R3TR TABU <b>111</b><u>1000</u>*, where 111 is the client and 1000 is the company code and * is a wild card entry for the rest of the key. This means transport all entries for client 111 and company code 1000. In this cause your transport can hold multiple entries:

R3TR TABU 1111000*

R3TR TABU 1112000*

R3TR TABU 1113000* and so on, but you cannot further split the entries based on FLD3.

Another scenario:

A. FLD1 is MANDT modeled after SY-MANDT.

B. FLD3 is custom Z field of type INT4.

In this case, you can only transport entries at the client level because your transport key will look like R3TR TABU 111*. This means transport all entries for client 111.

A third scenario:

A. FLD3 is custom Z field of type INT4. The transportable table has only one key field and it is not of type CHAR or NUMC.

In this case, your transport key is R3TR TABU * - The entire key is a full-on wild card. This will transport the entire table.

You need to assess how big of a task it is to change the field data type and adjust the data. Programs, screen fields and other tables might be affected. If it is feasible, change the field's data type to CHAR or NUMC. Or else you will be building transports by hand and transporting more entries than necessary.

[former_member217157]

Thanks for your reply. Do you see this as a limitation to transport request which should be corrected. Has this been mentioned somehwere in SAP docs?. At the least it should prevent creating a C/S table with INT4 key.

Yes, it will be difficult to change the datamodel at this point, but we may have to choose that route if it the only option.

[Former Member]

Agree with you. SAP shouldn't let you create transportable entries with non-CHAR fields. It might be easier for you to write your own custom "transport" program if you are unwilling to change the data model. You could use FM RFC_READ_TABLE and "pull" the entries from the target system.

SAP would have probably corrected it - they had more that 20 years to do it - but they probably see some technical reasons not to.