EXPORT TO MEMORY/DATABASE/SHARED BUFFER

EXPORT - Export data

Variants:

1. EXPORT obj1 ... objn TO MEMORY.
2. EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.
3. EXPORT obj1 ... objn TO DATASET dsn(ar) ID key.
4. EXPORT obj1 ... objn TO SHARED BUFFER dbtab(ar) ID key.
5. EXPORT (itab) TO ... .


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

Effect

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

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.

Effect

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

Effect

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

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 2

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

1. ... FROM f (for each field to be exported)
2. ... CLIENT g (after dbtab(ar))
3. ... USING form

Effect

Exports the objects obj1 ... objn (fields, structures or tables) as a data cluster to the database table dbtab.
The database table dbtab 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.

The table dbtab specified after DATABASE must be declared under TABLES.

Example

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

TABLES INDX. 
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE', 
	F1(4), F2 TYPE P, 
	BEGIN OF ITAB3 OCCURS 2, 
		CONT(4), 
	END OF ITAB3. 
* Before the export, fille the data 
* fields before CLUSTR. 
INDX-AEDAT = SY-DATUM. 
INDX-USERA = SY-UNAME. 
* Export data. 
EXPORT F1 F2 ITAB3 TO 
	 DATABASE INDX(ST) ID INDXKEY.

Effect

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

Effect

Stores the data objects in the client g (if the import/export database table dbtab is client-specific).


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 database table work area; it has one parameter which describes the operation (READ, UPDATE or INSERT ). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.


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

Variant 3

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

Variant 4

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


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

Additions:
1. ... FROM f (for each field to be exported)
2. ... CLIENT g (after dbtab(ar))

Effect

Exports the objects obj1 ... objn (fields, structures or tables) as a data cluster to the cross-transaction application buffer.
The table dbtab must have a
standard structure.
The buffer area for the table dbtab 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).

You must declare the table dbtab specified after SHARED BUFFER under TABLES.

Example

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

TABLES INDX. 
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE', 
	F1(4), F2 TYPE P, 
	BEGIN OF ITAB3 OCCURS 2, 
		CONT(4), 
	END OF ITAB3. 
* Before export, fill the data fields 
* before CLUSTR. 
INDX-AEDAT = SY-DATUM. 
INDX-USERA = SY-UNAME. 
* Export data. 
EXPORT F1 F2 ITAB3 TO 
	 SHARED BUFFER INDX(ST) ID INDXKEY.

Effect

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

Effect

Exports the data objects to the client g (if the import/export table dbtab is client-specific).

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

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 FROM f addition. If the table only has one column, or the second column only contaisn blanks, this corresponds to a static EXPORT without a FROM addition. In this case, the first column of the table (and second if applicable) should be of type Character.

DATA: BEGIN OF OBJ_TAB OCCURS 5, 
		CLUSTERNAME(30), 
		PROGRAMNAME(10), 
	END   OF OBJ_TAB. 
 
DATA: BEGIN OF B_PROG OCCURS 2, 
		FIELD_1 TYPE I, 
		FIELD_2 TYPE N, 
	END	OF B_PROG. 
 
DATA: A(10), 
	C_PROG LIKE SYST. 
 
MOVE:  'A'	TO OBJ_TAB-CLUSTERNAME. 
APPEND OBJ_TAB. CLEAR OBJ_TAB. 
 
MOVE:  'B'	TO OBJ_TAB-CLUSTERNAME, 
	 'B_PROG' TO OBJ_TAB-PROGRAMNAME. 
APPEND OBJ_TAB. CLEAR OBJ_TAB. 
 
MOVE:  'C'	TO OBJ_TAB-CLUSTERNAME, 
	 'C_PROG' TO OBJ_TAB-PROGRAMNAME. 
APPEND OBJ_TAB. CLEAR OBJ_TAB. 
 
EXPORT (OBJ_TAB) TO MEMORY ID 'ABCD'. 

The dynamic EXPORT statement corresponds to a static EXPORT statement.

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

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

Note

Runtime errors: