SAP NetWeaver AS ABAP Release 750, ©Copyright 2016 SAP AG. All rights reserved.
ABAP - Keyword Documentation → ABAP - Reference → Processing External Data → Data Clusters → EXPORT →
EXPORT - medium
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 } ...
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
Effect
The exported data cluster can be stored in a byte string xstr, in an internal table itab, in the
ABAP memory, in a database table dbtab, or in a shared memory area
(SHARED MEMORY or BUFFER specified) .
... DATA BUFFER xstr
Effect
If DATA BUFFER is specified, the data cluster is written to the elementary
data object xstr, which has to be of the type xstring. The previous content of xstr is overwritten completely.
Notes
... INTERNAL TABLE itab
Effect
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 rows if necessary. The first row contains the length occupied in the second row. The only table category allowed for itab are
standard tables without
secondary table keys.
Notes
... MEMORY ID id
Effect
If MEMORY is specified, the data cluster is written in to
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 identification.
Notes
Example
Two fields with two different IDs "P1" and "P2"
with the dynamic variant of the cluster definition are written to the ABAP memory. After the statement
IMPORT is executed, the contents of the fields text1 and text2 are swapped.
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
Effect
If DATABASE is specified, the data cluster with the ID id is stored in the database table dbtab and committed by the next database commit. In ABAP Dictionary, the database table must be defined with a fixed INDX-like structure. id expects a flat character-like data object containing an ID no longer than the key fields of the INDX-like table defined between the columns RELID and SRTF2. The ID is case-sensitive.
The two-character area ar, which must be specified directly, splits up the rows of the database table into multiple areas, so that data clusters with the same ID id can exist more than once in the database table.
After FROM, a work area wa can be specified that must have the same data type as the database 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 occupied by the data cluster of the database table. If the addition FROM wa is not specified within classes, no data transport takes place in 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 database table dbtab, the current values of the corresponding components of the table work area dbtab are written to the rows of the database table in the export.
If the database table dbtab is client-specific, 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.
Notes
Example
An internal table itab with the name tab and the ID "TABLE" is exported to the area "SQ"
of the database table DEMO_INDX_TABLE, filling the freely selectable components from the structure wa_indx.
TYPES:
BEGIN OF tab_type,
col1 TYPE i,
col2 TYPE i,
END OF tab_type.
DATA:
wa_indx TYPE demo_indx_table,
wa_itab TYPE tab_type,
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-timestamp = sy-datum && sy-uzeit.
wa_indx-userid = sy-uname.
EXPORT tab = itab
TO DATABASE demo_indx_table(SQ)
FROM wa_indx
ID 'TABLE'.
... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id
... SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT cl] ID id
Effect
If SHARED MEMORY or SHARED BUFFER is specified, the data cluster is stored in cross-transaction application buffers of the shared memory on the application server. All programs of the same application server have access to these buffers.
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 SHARED MEMORY buffer is reached, space must be freed using the statement DELETE FROM SHARED MEMORY; otherwise a handleable exception is raised. The buffer of SHARED BUFFER is cleared 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 ABAP Dictionary must be specified that has the same
structure if stored in the database table
itself. 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 if saved 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.
Notes