ABAP - Keyword Documentation →  ABAP - Reference →  Processing External Data →  Data Clusters →  EXPORT → 

EXPORT - medium

Quick Reference

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) .

Note

For optimization reasons, the binary content of the data cluster can be dependent on the way it is saved. When reconstructed, a data cluster saved in multiple parts is not necessarily the same as a data cluster saved as a single cluster This means that a data cluster can usually only be imported using an IMPORT statement that matches the save method.

Example

The program DEMO_DATA_CLUSTER demonstrates that the size of the data cluster is mostly independent of the way it is saved.

Alternative 1

... 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

Example

Exports an internal table to a byte string and saves it to a database table. After the byte string is read from the database table, the content of the data cluster can be imported to another internal table.

SELECT *
       FROM scarr
       INTO TABLE @DATA(itab).

DATA buffer TYPE xstring.
EXPORT itab = itab TO DATA BUFFER buffer.

MODIFY demo_expressions FROM @(
  VALUE #( id = 'B' xstring1 = buffer ) ).

...

DATA jtab TYPE TABLE OF scarr WITH EMPTY KEY.
SELECT SINGLE xstring1
       FROM demo_expressions
       WHERE id = 'B'
       INTO @buffer.

IF sy-subrc = 0.
  IMPORT itab = jtab FROM DATA BUFFER buffer.
ENDIF.
IF sy-subrc = 0.
  cl_demo_output=>display( jtab ).
ENDIF.

Alternative 2

... 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

Example

Exports an internal table to a data cluster in an internal table and imports it into another internal table.

TYPES:
  BEGIN OF bline,
    id    TYPE i,
    clstr TYPE x LENGTH 100,
  END OF bline.

SELECT *
       FROM scarr
       INTO TABLE @DATA(itab).

DATA buffer TYPE TABLE OF bline WITH EMPTY KEY.
EXPORT itab = itab TO INTERNAL TABLE buffer.

...

DATA jtab TYPE TABLE OF scarr WITH EMPTY KEY.
IMPORT itab = jtab FROM INTERNAL TABLE buffer.
IF sy-subrc = 0.
  cl_demo_output=>display( jtab ).
ENDIF.

Alternative 3

... 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

Exports two text strings labeled P1 and P2 into the ABAP memory. After the statement IMPORT is executed, the contents of the fields text1 and text2 are swapped.

DATA(id) = 'TEXTS'.

DATA(text1) = `Ike`.
DATA(text2) = `Tina`.

EXPORT p1 = text1
       p2 = text2 TO MEMORY ID id.

...

IMPORT p1 = text2
       p2 = text1 FROM MEMORY ID id.

Alternative 4

... 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. The 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, 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 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 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 export/import 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 export/import 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

Exports an internal table itab with the name scarr_tab and the ID SCARR to the range SC of the database table DEMO_INDX_BLOB. Here, the freely definable components are filled from the structure wa.

SELECT *
       FROM scarr
       INTO TABLE @DATA(itab).

DATA(wa) = VALUE demo_indx_blob(
  timestamp = CONV #( sy-datum && sy-uzeit )
  userid    = sy-uname ).

EXPORT scarr_tab = itab
  TO DATABASE demo_indx_blob(sc)
  FROM wa
  ID 'SCARR'.

Alternative 5

... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id


Alternative 6

... 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).

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 as 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 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

Example

Exports 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.

SELECT *
       FROM scarr
       INTO TABLE @DATA(itab).

DATA(wa) = VALUE demo_indx_blob(
  timestamp = CONV #( sy-datum && sy-uzeit )
  userid    = sy-uname ).

EXPORT scarr_tab = itab
  TO SHARED BUFFER demo_indx_blob(sc)
  FROM wa
  ID 'SCARR'.