EXPORT - Table Structure
- The first field must be a key field with the name MANDT of type CLNT for the client, if the data objects are to be saved as client-specific objects. This component does not apply if objects are saved as cross-client objects.
- The second field must be a key field with the name RELID of type CHAR and with length 2. The area saved here is specified as
- This must be followed by at least one key field of type CHAR with any name. The identifier specified
idin the length of the key field is saved here. If more than one key field is defined, the identifier is divided among them according to the respective length of the key fields. If the total length of the key fields is not sufficient for the identifier, it is truncated on the right side.
- The next field must be a key field with the name SRTF2 of type INT4. It contains the row numbers of a saved data cluster that can span multiple rows and that is filled automatically by the system.
- Any number of components with any name and type can follow, which are filled with values by specifying
FROM wa. The addition
TO waof the statement
IMPORTreads these fields again.
- The last two components must be called CLUSTR and CLUSTD and have the types INT2 and LRAW of any length. The current length of the field CLUSTD of each row is saved inCLUSTR, while CLUSTD contains the actual data cluster.
- The freely definable fields between SRTF2 and CLUSTR can be used to save status information for a stored data cluster, such as data, user, or language.
- The total length of all key fields (meaning the total length of MANDT, RELID, the key fields for the ID, and SRTF2) is limited to 900 bytes, like every AS ABAP database defined in ABAP Dictionary. If the table content is to be transported by specifying a key, a restriction of 120 bytes is required here too. Here, the key field SRTF2 does not usually need to be specified, since it only makes sense to transport all rows in a data cluster.
- The database table INDX delivered by SAP has the required structure and can be used as a template for creating custom database tables or for test purposes. In live programs, however, it is strongly recommend that separate INDX-like database tables are used. There are two reasons for this. Firstly, when storing data in the INDX, there is a risk of unintentionally overwriting or deleting other programs. Secondly, the freely definable fields between SRTF2 and CLUSTR do not normally lend themselves to this type of use.
- For information about how to handle INDX-like database tables using SQL, see SQL Access to INDX-Like Database Tables.