EXPORT - Export data

Variants:




1. EXPORT obj1 ... objn TO DATA BUFFER f.

2. EXPORT obj1 ... objn TO INTERNAL TABLE itab.
2. EXPORT obj1 ... objn TO MEMORY.

3. EXPORT obj1 ... objn TO SHARED MEMORY itab(ar) ID key.

4. EXPORT obj1 ... objn TO SHARED BUFFER itab(ar) ID key.

5. EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.

6. EXPORT obj1 ... objn TO DATASET dsn(ar) ID key.

7. EXPORT (itab) TO ... .

In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. See Storing Data Clusters.

Variant 1

EXPORT obj1 ... objn TO DATA BUFFER f.

Extras:


1. ... = f (for each field to be exported)

2. ... FROM f (for each field to be exported)

3. ... COMPRESSION ON/OFF (as the last addition)

4. ... CODE PAGE HINT g (for internal use only)

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in the Cluster

Effect

Stores a data cluster in the data buffer f, where f has the type XSTRING. The objects declared, obj1 ... objn, are stored as a cluster in the data buffer f. They can be fields, structures, complex structures, or tables.

Notes

You cannot export the header lines of internal tables because specifying the name of an internal table with a header line always exports the actual table data.

Example

Exports two fields and an internal table to a data buffer:

TYPES: BEGIN OF ITAB3_TYPE,
          CONT(4),
       END OF ITAB3_TYPE.
DATA: XSTR  TYPE XSTRING,
      F1    TYPE C LENGTH 4,
      F2    TYPE P,
      ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH
                 NON-UNIQUE DEFAULT KEY INITIAL SIZE 2.

EXPORT F1    FROM F1
       F2    FROM F2
       ITAB3 FROM ITAB3
       TO DATA BUFFER XSTR.

Addition 1

... = f (for each object to be exported)

Effect

Exports the contents of the data object f and stores them under the name declared before the "equal to" (=) sign.

Addition 2

... FROM f (for each object to be exported)

Effect

Exports the contents of the data object f and
stores them under the name declared before the FROM addition.

Addition 3

... COMPRESSION ON/OFF (as the last addition)

Effect

Specifies whether the data stored in the data buffer is to be compressed or not. The default value is "not compressed".


Addition 4

... CODE PAGE HINT g (for internal use only)

Effect

For non-unique code pages (such as 6200), you can use this addition to specify which code page g should be used to interpret the data during import (such as 8000 (Japanese)). g must be a character-type field.

Note

Variant 2

EXPORT obj1 ... objn TO INTERNAL TABLE itab.


Extras:

1. ... = f (for each field to be exported)

2. ... FROM f (for each field to be exported)

3. ... COMPRESSION ON/OFF (as the last addition)

4. ... CODE PAGE HINT g (only for internal use)

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See No implicit field names in cluster

Effect

Stores a Data Cluster in the internal table itab. The first column of the table must be of the predefined ABAP Dictionary type INT2 (for the length used) and the second column must be type X (for the actual data). To define the first column you must refer to a data element in the ABAP Dictionary that has predefined type INT2. The specified objects obj1 ... objn (fields, structures, complex structures, or tables) are stored as a cluster in the internal table itab, occupying several rows if necessary.

Notes

Data, object, and interface references cannot be exported.

Example

Export of two fields and one internal table into an internal table:

TYPES: BEGIN OF ITAB3_TYPE,
          CONT(4),
       END OF ITAB3_TYPE.

DATA:  F1    TYPE C LENGTH 4,
       F2    TYPE P,
       ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH
                  NON-UNIQUE DEFAULT KEY INITIAL SIZE 2.

TYPES: BEGIN OF ITAB_LINE,
         CLUSTR       TYPE INT2,
         CLUSTD(1000) TYPE X,
       END OF ITAB_LINE.

DATA: ITAB TYPE TABLE OF ITAB_LINE.
EXPORT F1    FROM F1
       F2    FROM F2
       ITAB3 FROM ITAB3
       TO INTERNAL TABLE ITAB.

Addition 1

... = f (for each object to be exported)

Effect

The contents of data object f is exported and stored under the name specified before =.

Addition 2

... FROM f (for each object to be exported)

Effect

The contents of data object f is exported and stored under the name specified before FROM.

Addition 3

... COMPRESSION ON/OFF (as last addition)

Effect

Specifies whether storage in the internal table should be compressed or not. Without this addition the data is stored uncompressed.

Addition 4

... CODE PAGE HINT g (only for internal use)

Effect

With ambiguous codepages (for example 6200), you can use this addition to specify with which codepage g the data is to be interpreted when importing (for example 8000 (Japanese)). g must be a character-type field.

Note

Variant 3

EXPORT obj1 ... objn TO MEMORY.


Extras:

1. ... = f (for each field to be exported)

2. ... FROM f (for each field to be exported)

3. ... ID key

4. ... COMPRESSION ON/OFF (as the last addition)

/

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Must Enter an Identifier and You Cannot Use Implicit Field Names in Clusters.

Effect

Exports the objects obj1 ... objn as a data cluster to the ABAPmemory. The objects, obj1 ... objn, can be fields, structures, complex structures, or tables.
If you call a transaction, report or dialog module (with CALL TRANSACTION, SUBMIT or CALL DIALOG), the contents of the ABAP memory are retained, even across several levels of the call chain. The transaction called can then retrieve the data from the ABAP memory, using IMPORT ... FROM MEMORY. Each new EXPORT ... TO MEMORY statement overwrites any old data in the ABAP memory - no data is appended.
If the processing leaves the deepest level of the call chain, the ABAP memory is released.

Notes

You cannot export the header lines of internal tables because specifying the name of an internal table with a header line always exports the actual table data.

Addition 1

... = f (for each object to be exported)

Effect

Exports the contents of the data object f and stores them under the name specified before =.

Addition 2

... FROM f (for each object that is to be exported)

Effect

Exports the contents of the data object f and stores them under the name entered in FROM.

Addition 3

... ID key

Effect

Stores the exported data under the ID key in the ABAP memory. You can then use the ID to read it in again (with IMPORT). The ID can be up to 60 characters long.

Addition 4

... COMPRESSION ON/OFF (as the last addition)

Effect

Specifies whether the data stored in the data buffer is to be compressed or not. The default value is "not compressed".

Note

If you store data both with and without an ID, the data stored without an ID remains separate and you can re-import it (using IMPORT without ID).

Related

IMPORT FROM MEMORY, FREE MEMORY

Variant 4

EXPORT obj1 ... objn TO SHARED MEMORY itab(ar) ID key.


Extras:

1. ... = f (for each field to be exported)

2. ... FROM f (for each field to be exported)

3. ... CLIENT g (in front of ID key )

4. ... FROM wa (after ID key or itab(ar)

5. ... COMPRESSION ON/OFF (as the last addition)

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.

Effect

Stores the data objects, obj1 ... objn (fields, structures, or tables), as a data cluster in the shared memory. You must use itab to specify a database table although the system does not write the data to this table but to a memory table with an appropriate structure.
The database table itab specified must have a standardized structure.
The structure of itab is used to set up a table in the memory which is split into various areas that are logically related ( ar, 2-character name).
A collection of data objects - that is, a data cluster - can be exported to an area in this buffer as an entity, using this key (the key field).
You can import individual data objects in this cluster using IMPORT.

The shared memory can be filled up to an internal maximum, which can be set using the profile parameter rsdb/obj/buffersize. With EXPORT TO SHARED BUFFER, you must empty the shared memory explicitly using DELETE FROM SHARED MEMORY to make room.

Notes

You cannot export the header lines of internal tables because specifying the name of an internal table with a header line always exports the actual table data.

Addition 1

... = f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the name declared.

Addition 2

... FROM f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the name declared.

Addition 3

... CLIENT g (vor ID key)

Effect

Stores the data objects in the client g (provided the import/export table itab is client-specific). The client g must be a character-type data object (but not a string).

Addition 4

... FROM wa (as the last addition, or after itab(ar))

Effect

You need to use this addition to store user data fields in the application buffer. You use wa instead of the table work area. The work area declared must have the same line type as the table dbtab.

Addition 5

... COMPRESSION ON/OFF (as the last addition)

Effect

Specifies whether the data stored in the shared memory is to be compressed or not. The default value is "not compressed".

Variant 5

EXPORT obj1 ... objn TO SHARED BUFFER itab(ar) ID key.


Extras:

1. ... FROM f (for each field to be exported)

2. ... CLIENT g (after dbtab(ar))

3. ... CLIENT g (before the ID key)

4. ... FROM wa (after ID key or after itab(ar))

5. ... COMPRESSION ON/OFF (als letzter Zusatz)

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.

Effect

Exports a data cluster to the cross-transaction application buffer. The objects specified obj1 ... objn (fields, structures, or tables) are stored as a cluster in the buffer. You must use itab to specify a database table altough the system does not write the data to this table but to a memory table with an appropriate structure.
The table itab specified must have a standardized structure.
The system creates a table of the structure itab in the buffer, which is divided into different logically related areas ( ar, 2-character name).
A collection of data objects (known as a data cluster) can be be exported to an area of this buffer under a freely definable key (field key).
You can use IMPORT to import single data objects of this cluster (as long as the data is not pushed out of the buffer).

The application buffer can be filled up to an internal maximum, which can be set using the profile parameter rsdb/obj/buffersize. With EXPORT TO SHARED BUFFER, if the limit is reached, the buffer is automatically emptied by a displacement procedure similar to the LRU procedure (Least Recently Used). It removes those data objects from the buffer that were used the least.

Notes

Example

Export two fields and an internal table to the buffer with the structure INDX:

TYPES: BEGIN OF ITAB3_TYPE,
          CONT(4),
       END OF ITAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
      F1(4), F2 TYPE P,
      ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH
                 NON-UNIQUE DEFAULT KEY INITIAL SIZE 2,
      WA_INDX TYPE INDX.

* Before export, fill the data fields
* before CLUSTR.
WA_INDX-AEDAT = SY-DATUM.
WA_INDX-USERA = SY-UNAME.
* Export der Daten.
EXPORT F1    FROM F1
       F2    FROM F2
       ITAB3 FROM ITAB3
       TO SHARED BUFFER INDX(ST) FROM WA_INDX ID INDXKEY.

Addition 1

... FROM f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the specified name.

Addition 2

... FROM f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the specified name.

Addition 3

... CLIENT g (before ID key)

Effect

Exports the data objects to the client g (if the import/export table dbtab is client-specific). The client g must be a character-type data object (but not a string).

Addition 4

... FROM wa (as last addition or after itab(ar))

Effect

You must use this addition to save user data fields in the application buffer. The work area entered, wa, is used instead of the table work area. The work area entered must have the same structure as the named table itab.

Example

DATA WA LIKE INDX.
DATA F1.
WA-AEDAT = SY-DATUM.
WA-USERA = SY-UNAME.
WA-PGMID = SY-REPID.
EXPORT F1 = F1 TO SHARED BUFFER INDX(AR)
               CLIENT '001' ID 'TEST'
               FROM WA.

Addition 5

... COMPRESSION ON/OFF (as the last addition)

Effect

Specifies whether the data stored in the cross-transaction application buffer is to be compressed or not. The default value is "not compressed".

Variant 6

EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.

Extras:


1. ... = f (for each field to be exported)

2. ... FROM f (for each field to be exported)

3. ... CLIENT g (before ID key )

4. ... USING form

5. ... FROM wa (after ID key or dbtab(ar))

6. ... COMPRESSION ON/OFF (as the last addition)

7. ... CODE PAGE HINT g (for internal use only) )

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters and Cannot Use Table Work Areas.

Effect

Exports a data cluster to the database table dbtab. The objects specified, obj1 ... objn (fields, structures, or tables) are stored as a cluster in the database table dbtab.
The database table dbtab specified must have a standardized structure.
The database table dbtab is divided into different logically related areas (ar, 2-character name).
You can export collections of data objects (known as data clusters) under a freely definable key (field key) to an area of this database.
IMPORT allows you to import individual data objects from this cluster.

Notes

You must also enter the work area explicitly in classes - that is, addition 5 is mandatory.

Example

Export two fields and an internal table to the database table INDX:

TYPES: BEGIN OF ITAB3_TYPE,
          CONT(4),
       END OF ITAB3_TYPE.

DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
      ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH NON-UNIQUE
                 DEFAULT KEY INITIAL SIZE 2,
      WA_INDX TYPE INDX.
* Before the export, fill the data
* fields before CLUSTR.
WA_INDX-AEDAT = SY-DATUM.
WA_INDX-USERA = SY-UNAME.
* Export data.
EXPORT F1    FROM F1
       F2    FROM F2
       ITAB3 FROM ITAB3
       TO DATABASE INDX(ST)  FROM WA_INDX ID INDXKEY.
       DATABASE INDX(ST) ID INDXKEY.

Addition 1

... = f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the specified name in the database.

Addition 2

... FROM f (for each object to be exported)

Effect

Exports the contents of the field f and stores them under the specified name in the database.

Addition 3

... CLIENT g (after dbtab(ar))

Effect

Stores the data objects in the client g (if the import/export database table dbtab is client-specific). The client g must be a character-type data object (but not a string).

Addition 4

... USING form

Note

This statement is for internal use only.

Incompatible changes or further developments may occur at any time without warning or notice.


Effect

Does not export the data to the database table. Instead, calls the FORM routine form for every record written to the database without this addition. The name of the routine has the format <name of database table>_<name of form>. The routine can take the data from the work area of the database table; it has a parameter, which describes the operation mode (READ, UPDATE or INSERT). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.

Addition 5

... FROM wa (as last addition, or after dbtab(ar))

Effect

You must use this addition to save user data fields in a cluster database. The work area entered, wa, is used instead of a table work area. The work area entered must have the same structure as the named table dbtab.

Example

DATA WA LIKE INDX.
DATA F1.
WA-AEDAT = SY-DATUM.
WA-USERA = SY-UNAME.
WA-PGMID = SY-REPID.
EXPORT F1 = F1 TO DATABASE INDX(AR)
               CLIENT '002' ID 'TEST'
               FROM WA.

Addition 6

... COMPRESSION ON/OFF (as the last addition)

Effect

Specifies whether the data stored in the database table is to be compressed or not. The default value is "not compressed".

Addition 7

... CODE PAGE HINT g (for internal use only)

Effect

For non-unique code pages (such as 6200), you can use this addition to specify which code page g should be used to interpret the data during import (such as 8000 (Japanese)). g must be a character-type field.

Note

Exceptions


Errors in the structure of the EXPORT/IMPORT database table can cause runtime errors.

Variant 7

EXPORT obj1 ... objn TO DATASET dsn(ar) ID key.


This variant is not allowed in an ABAP Objects context.

See Cannot Use Clusters in Files

Note

Variant 8

EXPORT (itab) TO ... .


Effect

Specifies the objects to be exported in the internal table itab. You can use this variant instead of a static object list in each of the variants 1 to 5. All of the additions allowed in the static cases are also allowed in this 'dynamic' variant. The internal table itab may not be a HASHED TABLE or ANY TABLE.

Note

Constructing the internal table itab:

The first column of the table contains the object name in a data cluster. In other words, it corresponds to the static obj1 ... objn. The second column contains the different name in the program (if applicable), and corresponds to field f in the = f or FROM f addition. If the table only has one column, or the second column only contains blanks, this corresponds to a static EXPORT without a = or FROM addition. In this case, the first column of the table (and second if applicable) should be of type CHAR or STRING.

Example


TYPES: BEGIN OF OBJ_LINE,
         CLUSTERNAME(30),
         PROGRAMNAME(10),
       END OF OBJ_LINE.

DATA: OBJ_TAB TYPE STANDARD TABLE OF OBJ_LINE,

      OBJ_WA  TYPE OBJ_LINE.

TYPES: BEGIN OF B_LINE,
         FIELD_1    TYPE I,
         FIELD_2(1) TYPE N,
       END OF B_LINE.

DATA: B_PROG TYPE STANDARD TABLE OF B_LINE.

DATA: A(10),
      C_PROG LIKE SYST.

MOVE:  'A'      TO OBJ_WA-CLUSTERNAME.
APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

MOVE:  'B'      TO OBJ_WA-CLUSTERNAME,
       'B_PROG' TO OBJ_WA-PROGRAMNAME.
APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

MOVE:  'C'      TO OBJ_WA-CLUSTERNAME,
       'C_PROG' TO OBJ_WA-PROGRAMNAME.
APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.

EXPORT (OBJ_TAB) TO MEMORY ID 'ABCD'.

The dynamic EXPORT statement corresponds to a static EXPORT statement.

EXPORT A = A  B = B_PROG  C = C_PROG TO MEMORY ID 'ABCD'.

The system exports the field A with the name A, the internal table B_PROG under the name B, and the structure C_PROG under the name C.

Exceptions

Catchable Exceptions


CX_SY_EXPORT_BUFFER_NO_MEMORY


CX_SY_EXPORT_NO_SHARED_MEMORY

CX_SY_FILE_AUTHORITY

CX_SY_FILE_IO

CX_SY_FILE_OPEN

Non-Catchable Exceptions

Additional help

Saving Data Objects in Memory

Saving Data Objects in Cluster Databases