Kontakt

Ansicht
Dokumentation

ABENEXPORT_DATA_CLUSTER_INDX - EXPORT DATA CLUSTER INDX

ABENEXPORT_DATA_CLUSTER_INDX - EXPORT DATA CLUSTER INDX

PERFORM Short Reference   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.
SAP E-Book

Export/Import Tables

When storing data clusters in database tables and application buffers of the shared memory, database tables with one of the following structures must be specified: These database tables are referred to as export/import tables.

Notes

  • The structure for data clusters in a row is the newer variant and is recommended for new database tables.
  • Status information about the actual data cluster, such as date, user, or language, can be stored in freely definable fields.

Structure for Data Clusters in One Row

In export/import table structures like this, the data cluster is stored in a single row in a column CLUSTD of the type RAWSTRING (BLOB).

  • If the data objects are to be stored as client-dependent objects, the first field must be a key field with the name MANDT of type CLNT for the client. This component is not required for client-independent storage.
  • The next field must be a key field with the name RELID of type CHAR and with length 2. The specification of the area ar is stored here.
  • This must be followed by at least one key field of type CHAR with any name. The identifier specified in id within the length of the key field is stored 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.
  • Any number of fields with freely selectable name and type can follow, which are filled with values by specifying FROM wa. The addition TO wa of the statement IMPORT reads these fields again.
  • The final field must be called CLUSTD and linked with the data element INDX_CLUST_BLOB with the dictionary type RAWSTRING. This column is given the actual data cluster.

Note

The total length of all key fields, that is the total length of MANDT, RELID, and the key fields for the ID, and SRTF2, is limited to 900 bytes, like every AS ABAP database defined in the ABAP Dictionary. If the table content is to be transported by specifying a key, a limit of 120 bytes is required here.

Example

The database table DEMO_INDX_BLOB is an example of how data clusters are stored in a single row.

Structure for Data Clusters in Multiple Rows

In export/import table structures like this, the data cluster is stored in a column CLUSTD of the type LRAW and can be split multiple rows. The structure requires the additional columns SRTF2 and CLUSTR to manage this repository.

  • The structure starts with the same key fields as in the structure above for data clusters in a single row.
  • The next field must be a further key field with the name SRTF2 of type INT4. It contains the row numbers of the data cluster stored in the field CLUSTD. This cluster can span multiple rows and is filled automatically by the system. If more rows are required than allowed by the value range of SRTF2, an uncatchable exception is raised.
  • Any number of fields with custom names and types can follow. The same applies to these fields as to the structure above for data clusters in a single row.
  • 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 stored in CLUSTR, while CLUSTD contains the actual data cluster, which can span multiple rows.

Notes

  • When a data cluster is split across multiple rows, the associated administration data must be stored for each row. In each row, the content of the custom fields are stored redundantly.
  • The additional key field SRTF2 is part of the total length of all key fields. When table content is transported by specifying a key, the key field SRTF2 does not usually need to be specified since only transports of all rows in a data cluster are feasible.
  • A database table INDX, delivered by SAP, has the layout for a data cluster in multiple rows and can be used as a template for creating custom database tables or for test purposes. In production programs, however, it is strongly recommended that separate export/import tables are used:
  • When data is stored in the table INDX, data is at risk of being overwritten or deleted unintentionally by other programs.

  • The custom fields between SRTF2 and CLUSTR do not usually match their own application.

  • The table INDX has the delivery class A and is client-dependent. The delivery class L may be better suited for storing temporary data. If the data needs to be client-independent data, the table used should not contain a client column. This prevents redundant data from being stored.

  • New export/import tables should be created with a BLOB column CLUSTD.

  • Old export/import tables can also occur, however, where the column SRTF2 has the data type INT1 or INT2. In these tables, a data cluster cannot cover more rows than allowed by the value range of these types.

Example

The database table DEMO_INDX_TABLE is an example of how data clusters are stored in multiple rows.






CL_GUI_FRONTEND_SERVICES - Frontend Services   CPI1466 during Backup  
This documentation is copyright by SAP AG.

Length: 8186 Date: 20240426 Time: 063621     sap01-206 ( 139 ms )