EXPORT - Table Structure
- The first field must be a key field named MANDT of type CLNT for the client, if you want to store the data objects client-specifically. For a cross-client storage, this component does not apply.
- The second field must be a key field named RELID of type CHAR and length 2. It stores the area
- After that, at least one key field of type CHAR of any name must follow. It stores the identifier
idin the length of the key field. 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 named SRTF2 of type INT4. It contains the row numbers of a stored data cluster that can extend over several rows and is filled automatically by the system.
- Then any number of components with freely choosable names and types may follow, which are provided
with values by the specification of
FROM wa. Addition
TO waof the
IMPORTstatement reads these fields out again.
- The last two components must be named CLUSTR and CLUSTD and be of types INT2 and LRAW of any length. In CLUSTR, the current length of field CLUSTD of each row is stored, while CLUSTD contains the actual data cluster.
- The freely definable fields between SRTF2 and CLUSTR can be used to store status information for a stored data cluster, such as data, user, or language.
- The total length of all keys fields (MANDT, RELID, the key fields for the ID, and SRTF2) is restricted to 900 bytes (as for each AS ABAP relational database). If the table content is to be transported by specifying a key, this must be restricted to 120 bytes, whereby the SRTF2 key field does not generally have to be specified since it only makes sense to transport all of the rows of a data cluster.
- Database table INDX delivered by SAP has the required structure and can be used as a template for creating your own database tables or for test purposes. In live programs, however, we expressly recommend that you work with your own INDX-type database tables. 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 on how to handle INDX-type database tables with SQL, see SQL Access to INDX-Type Database Tables.