... { 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 } ... .
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
The exported data cluster can be stored
in a byte string xstr, in an internal table itab, in the
ABAP memory, in a data base table
dbtab or in a shared memory area (Specification SHARED MEMORY or BUFFER) .
... DATA BUFFER xstr
When specifying DATA BUFFER, the data cluster is written
in the elementary data object xstr, which has to be of the type xstring.
A common application of the addition DATA BUFFER is storage
of the generated data cluster in a field of a database table with the corresponding data type. In this
case, you should consider compression of the data cluster using the addition
COMPRESSION, as by default, compression as a medium is only switched on by a direct specification of DATABASE.
... INTERNAL TABLE itab
When specifying INTERNAL TABLE, the data cluster is stored
in the internal table itab. The first column of
itab has to be of the data type
s, and the second column must have the type x.
Depending on the width of the second column, the data is stored in multiple table rows if necessary. The first row contains the length occupied in the second row. As table type, you can only use
standard tables for itab.
... MEMORY ID id
When you specify MEMORY, the data cluster is written to the
ABAP Memory with the stated ID id. id is expected to be a
flat
character-type data object which
contains an identification with a maximum of 60 characters. An already existing data cluster with the
same identification id is completely overwritten. By the
identification in id, a data cluster is identified in the memory and can be read again with the same identification.
Obsolete short form
The addition ID can be omitted outside classes. However,
this is prone to errors, as all EXPORT statements without identification overwrite the same data cluster.
A data cluster in the ABAP memory is available to all programs within a call sequence, whereby data can be handed over to called programs.
Two fields with two different identifications "P1" and
"P2" with the dynamic variant of the cluster definition
are written to the ABAP Memory. After execution of the statement
IMPORT, the contents of the fields text1 and text2 are interchanged.
TYPES:
BEGIN OF tab_type,
para TYPE string,
dobj TYPE string,
END OF tab_type.
DATA:
id TYPE c LENGTH 10 VALUE 'TEXTS',
text1 TYPE string VALUE `IKE`,
text2 TYPE string VALUE `TINA`,
line TYPE tab_type,
itab TYPE STANDARD TABLE OF tab_type.
line-para = 'P1'.
line-dobj = 'TEXT1'.
APPEND line TO itab.
line-para = 'P2'.
line-dobj = 'TEXT2'.
APPEND line TO itab.
EXPORT (itab) TO MEMORY ID id.
IMPORT p1 = text2
p2 = text1 FROM MEMORY ID id.
... DATABASE dbtab(ar) [FROM wa] [CLIENT cl] ID id
When specifying DATABASE, the data cluster with the identification id is stored in the data base table dbtab and stored permanently at the next database-commit. For id, a flat character-type data object is expected that contains an identification of 105 or 108 characters at maximum, depending on whether the addition CLIENT is stated or not. The data base table has to be defined in the ABAP Dictionary with a fixated predetermined structure.
The double-digit area ar, which must be specified directly, splits up the rows of the database table into several areas, so that data clusters with the same identification id can exist multiple times in the data base table.
After FROM, a work area wa can be specified, which has to have the same data type as the data base table dbtab. When exporting, the current values of the components of wa, which aresituated between the fields SRTF2 and CLUSTR, are written in all the rows occupied by the data cluster of the data base table.
If the data base table dbtab is client-specific, you can specify a flat character-type field cl after the additionCLIENT, which contains a client identifier. If you do not specify the addition, the current client is used. The row MANDT of every row occupied by the data cluster of the data base is filled with this client identification at export.
Obsolete short form
If outside classes, the addition FROM wa is not specified and instead a
Table work area is declared for the
data base table dbtab with the statement
TABLES, then, at export, the current values of the components of the table work area dbtab, which are situated between the fields
SRTF2
and CLUSTR are written in the rows of the database table.
During a migration from a non-Unicode database to a
Unicode system, data clusters in databases
are not converted. In a Unicode system, data clusters may therefore 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 contained in the stored data objects are stored according to the relevant platform.
An internal table itab is exported under the name
tab and the identification "TABLE" to the area
"XY"of the data base table INDX (delivered by SAP). The selectable components are provided by the structure
wa_indx.
TYPES:
BEGIN OF tab_type,
col1 TYPE i,
col2 TYPE i,
END OF tab_type.
DATA:
wa_indx TYPE indx,
wa_itab TYPE tab_type,
cl TYPE mandt VALUE '100',
itab TYPE STANDARD TABLE OF tab_type.
WHILE sy-index < 100.
wa_itab-col1 = sy-index.
wa_itab-col2 = sy-index ** 2.
APPEND wa_itab TO itab.
ENDWHILE.
wa_indx-aedat = sy-datum.
wa_indx-usera = sy-uname.
wa_indx-pgmid = sy-repid.
EXPORT tab = itab
TO DATABASE indx(XY)
FROM wa_indx
CLIENT cl
ID 'TABLE'.
... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id
... SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT cl] ID id
When specifying SHARED MEMORY or SHARED BUFFER, the data cluster is stored in cross-transaction application buffers of the shared memory on the application server, to which all programs of the same application server have access.
The two application buffers differ in respect to 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 buffer of SHARED MEMORY is reached, you must free some space using the statement DELETE FROM SHARED MEMORY, otherwise this leads to a treatable exception. The buffer of SHARED BUFFER is automatically cleared by a displacement procedure 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, whose line structure
is defined with dbtab. For dbtab, you have to specify a data base table from the ABAP dictionary that has the same structure as
structure if stored in the data base table. The line
area ar, the work area wa,
the optional client cl and the identification
wa have the same significance for the memory table, as if stored in a data base table with
the exception that the length of the identification is limited to id
59 resp. 62 characters depending on whether the addition CLIENT is specified or not.
When storing something in the shared memory, you refer to a data base table, even if the data is not stored in the table itself, but in an accordingly created memory table.
When exporting data, you overwrite a possibly existing data cluster with the same client
cl, line area ar and identification
id. If an existing data cluster is to be overwritten by a bigger one with
SHARED MEMORY, which would exceed the memory limit, this only leads to the deletion of the present data cluster.