Get Example source ABAP code based on a different SAP table
• DATA BUFFER EXPORT cluster • INTERNAL TABLE EXPORT cluster • MEMORY EXPORT cluster • ID EXPORT TO MEMORY • DATABASE EXPORT cluster • FROM EXPORT TO DATABASE • CLIENT EXPORT TO DATABASE • ID EXPORT TO DATABASE • SHARED MEMORY EXPORT cluster • FROM EXPORT TO SHARED MEMORY • CLIENT EXPORT TO SHARED MEMORY • ID EXPORT TO SHARED MEMORY • SHARED BUFFER EXPORT cluster • FROM EXPORT TO SHARED BUFFER • CLIENT EXPORT TO SHARED BUFFER • ID EXPORT TO SHARED BUFFER
EXPORT, medium Short Reference
ABAP_SYNTAX ... ${ DATA BUFFER xstr $} $| ${ INTERNAL TABLE itab $} $| ${ MEMORY ID id $} $| ${ DATABASE dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $} $| ${ SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $} $| ${ SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $} ...
ABAP_ALTERNATIVES: 1 ... DATA BUFFER xstr 2 ... INTERNAL TABLE itab 3 ... MEMORY ID id 4 ... DATABASE dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id 5 ... SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id 6 ... SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id
What does it do? The exported data cluster can be stored in a byte string xstr, in an internal table itab BEGIN_SECTION VERSION 5 OUT , in the ABAP memory, in a database table dbtab, or in a shared memory area (SHARED MEMORY or BUFFER specified). END_SECTION VERSION 5 OUT
Latest notes: NON_V5_HINTS For optimization reasons, the binary content of the data cluster can depend on the way it is stored. When reconstructed, a data cluster stored in multiple parts is not necessarily the same as a data cluster stored as a single cluster. This means that a data cluster can usually only be imported using an IMPORT statement that matches the storage method. Especially, a data cluster stored in a structure for export/import tables in multiple rows cannot necessarily be concatenated into a byte string that can be imported with FROM DATA BUFFER. Even data clusters stored in multiple rows can differ between storage methods. That means a data cluster stored with INTERNAL TABLE can differ from a data cluster for the same data in export/import tables, especially, if they were stored in different releases or for different code pages. ABAP_HINT_END BEGIN_SECTION VERSION 5 OUT
Example ABAP Coding
The program DEMO_DATA_CLUSTER demonstrates that the size of the data cluster is mostly independent of the way it is stored. ABAP_EXAMPLE_END END_SECTION VERSION 5 OUT
ABAP Alternative 1 ... DATA BUFFER xstr BEGIN_SECTION ID EXPORT-DATA-BUFFER
What does it do? If DATA BUFFER is specified, the data cluster is written to the elementary data object xstr, which must be of the type xstring. The previous content of xstr is overwritten completely.
Latest notes:
A data object xstr filled by EXPORT TO DATA BUFFER contains exactly one data cluster.
A common application of the addition DATA BUFFER is to store the new data cluster in a field of a DDIC database table with the corresponding data type. In this case, compressing the data cluster using the addition COMPRESSION should be considered, since, by default, compression as a medium is only activated if DATABASE is specified directly.
The content of a data object filled by EXPORT TO DATA BUFFER can only be evaluated using IMPORT FROM DATA BUFFER. In other evaluations, for example when comparing data clusters, the result is undefined. For example, the undefined content of alignment gaps in structures can produce different data clusters with structures that otherwise have the same content. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Export of an internal table to a byte string and storing it in a database table. After the byte string is read from the DDIC database table, the content of the data cluster can be imported into another internal table. ABEXA 00252 ABAP_EXAMPLE_END END_SECTION ID EXPORT-DATA-BUFFER
ABAP Alternative 2 ... INTERNAL TABLE itab BEGIN_SECTION ID EXPORT-ITAB
What does it do? If INTERNAL TABLE is specified, the data cluster is stored in the internal table itab. The previous content of itab is overwritten completely. The first column of itab must have the data type s or i and the second column must have the type x. Depending on the width of the second column, the data is stored across multiple table lines if necessary. The first column contains the length occupied in the second column. The only table category allowed for itab are standard tables without secondary table keys.
Latest notes:
An internal table itab filled by EXPORT TO INTERNAL TABLE contains exactly one data cluster.
The content of an internal table filled by EXPORT TO INTERNAL TABLE can only be evaluated using IMPORT FROM INTERNAL TABLE for the same reasons as for EXPORT TO DATA BUFFER.
The variant EXPORT TO DATA BUFFER is preferred over the variant EXPORT TO INTERNAL TABLE because it is easier to handle. An export to an internal table is beneficial only for very large data clusters and if the available memory is almost used up. This is because its memory is requested block by block, while the memory for a string must always be available in one piece. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Export of an internal table to a data cluster in an internal table and importing it into another internal table. ABEXA 00253 ABAP_EXAMPLE_END END_SECTION ID EXPORT-ITAB
ABAP Alternative 3 ... MEMORY ID id BEGIN_SECTION ID EXPORT-MEMORY
What does it do? If MEMORY is specified, the data cluster is written into the ABAP Memory with the ID specified in id. id expects a flat character-like data object containing a case-sensitive ID with a maximum of 60 characters. Any existing data clusters with the same ID id are completely overwritten. The ID in id identifies a data cluster in the repository and can be read again using the same ID.
Latest notes:
A data cluster in the ABAP memory is available to all programs within a call sequence, which makes it possible to pass data to called programs. NON_V5_HINTS
Outside of classes, an obsolete short form exists, in which the addition ID can be omitted. However, this is prone to errors, since all EXPORT statements without ID overwrite the same data cluster. ABAP_HINT_END
Example ABAP Coding
Export of two text strings labeled P1 and P2 into the ABAP memory. After the statement IMPORT is executed, the content of the fields text1 and text2 is swapped. ABEXA 00254 ABAP_EXAMPLE_END END_SECTION ID EXPORT-MEMORY
ABAP Alternative 4 ... DATABASE dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id BEGIN_SECTION ID EXPORT-DATABASE
What does it do? If DATABASE is specified, the data cluster is stored under the ID id in the DDIC database table dbtab and committed by the next database commit . The DDIC database table must be an export/import table with a predefined structure. id expects a flat character-like data object containing an ID no longer than the key fields of the export/import table defined between the columns RELID and SRTF2. The ID is case-sensitive. The two-character area ar, which must be specified directly, divides the rows of the database table into multiple areas, so that data clusters with the same ID id can occur more than once in the DDIC database table. After FROM, a work area wa can be specified that must have the same data type as the export/import table dbtab. In an export, the current values of the components of wa, which are located between the fields SRTF2 and CLUSTR, are written to all rows of the database table occupied by the data cluster. If the addition FROM wa is not specified within classes, no data transport takes place to these database fields. If the addition FROM wa is not specified outside of classes, but the statement TABLES is used to declare a table work area for the export/import table dbtab, the current values of the corresponding components of the table work area dbtab are written to the rows of the DDIC database table in the export. If the export/import table dbtab is client-dependent, a flat character-like field cl can be specified after the addition CLIENT. This field contains a client ID. If the addition is not specified, the current client is used. The column MANDT of every row in the database table occupied by the data cluster is filled by this client ID in the export.
Latest notes:
The statement EXPORT ... TO DATABASE sets a database lock until the next database commit or rollback. If used incorrectly, this can produce a deadlock.
Data clusters in databases are not converted when migrating from a non-Unicode database to a Unicode system . In a Unicode system, therefore, data clusters may sometimes exist that contain non-Unicode characters. These characters are automatically converted to Unicode characters in each import. When data is exported in Unicode systems, any Unicode characters in the stored data objects are stored in accordance with the relevant platform.
Since each client represents a self-contained unit, the addition CLIENT must not be used in application programs. NON_V5_HINTS
The statement EXPORT ... TO DATABASE does not support table buffering.
It is still possible to use a table work area implicitly (instead of using FROM wa explicitly). This should be considered an obsolete short form, however. ABAP_HINT_END
Example ABAP Coding
Exports an internal table itab with the name scarr_tab and the ID SCARR to the range SC of the DDIC database table DEMO_INDX_BLOB. Here, the freely definable components are filled from the structure wa. ABEXA 00255 ABAP_EXAMPLE_END END_SECTION ID EXPORT-DATABASE
ABAP Alternative 5 ... SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id
ABAP Alternative 6 ... SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id BEGIN_SECTION ID EXPORT-SHARED
What does it do? If SHARED MEMORY or SHARED BUFFER is specified, the data cluster is stored in cross-transaction application buffers of the shared memory on of the current ABAP_ASINSTANCE . All programs of the same ABAP_ASINSTANCE have access to these buffers. The two application buffers differ in how the system behaves when reaching the memory limit. Both application buffers can be filled to an internal maximum limit, which can be adjusted using the profile parameter rsdb/esm/buffersize_kb (SHARED MEMORY) and rsdb/obj/buffersize (SHARED BUFFER).
Before the maximum limit of the SHARED MEMORY buffer is reached, space must be freed using the statement DELETE FROM SHARED MEMORY; otherwise a catchable exception is raised.
The buffer of SHARED BUFFER is emptied automatically by a displacement when it reaches the maximum limit. This procedure deletes the least used data objects from the buffer. When storing the data, the system creates a memory table in the application buffer. The row structure of this table is defined using dbtab. For dbtab, a database table from the ABAP Dictionary must be specified that has the structure of an export/import table. The row area ar, the work area wa, the optional client cl, and the ID id have the same significance for the memory table as when stored in a database table, with the exception that the length of the ID in id is limited to 59 or 62 characters depending on whether the addition CLIENT is specified or not.
Latest notes:
When storing data in the shared memory, a reference is made to an export/import table, even if the data is not stored in the table itself, but in an appropriately structured memory table.
The length of the key fields of the addressed export/import table between the columns RELID and SRTF2 cannot exceed 59 or 62 characters, depending on whether a client column exists.
When data is exported, any data clusters that have the same client cl, row area ar, and ID id are overwritten. If an existing data cluster is to be overwritten by a bigger one when using SHARED MEMORY, and this would exceed the memory limit, this only deletes the existing data cluster.
Instead of storing data clusters in the shared memory, it is best to use shared objects. Shared objects make it possible to store objects with complex dependencies, can be processed like regular objects, and enable multiple users to access the shared memory without any copying effort. NON_V5_HINTS ABAP_HINT_END
Example ABAP Coding
Export of an internal table itab with the name scarr_tab and the ID SCARR to the cross-transaction application buffer. The row structure of the memory table is the same as the export/import table DEMO_INDX_BLOB. ABEXA 00256 ABAP_EXAMPLE_END END_SECTION ID EXPORT-SHARED
