IMPORT FROM MEMORY/DATABASE/SHARED BUFFER

IMPORT - Get data

Variants:

1. IMPORT obj1 ... objn FROM MEMORY.
2. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
3. IMPORT obj1 ... objn FROM LOGFILE ID key.
4. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
5. IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
6. IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar) ID key.
7. IMPORT (itab) FROM ... .


1. ... TO f (for each object to be imported)
2. ... ID key

Effect

Imports data objects obj1 ... objn (fields, structures, complex structures or tables) from a data cluster in the ABAP memory (see EXPORT ). Reads in all data without an ID that was exported to memory with "EXPORT ... TO MEMORY.". In contrast to the variant IMPORT FROM DATABASE, it does not check that the structure matches in EXPORT and IMPORT.

SY-SUBRC = 4:

The data objects could not be imported, probably
because the ABAP/4 memory was empty.
The contents of all objects remain unchanged.

Note

,You should always use the addition 2 (... ID key) with the statement. Otherwise, the effect of the variant is not certain (EXPORT statements in different parts of a program overwrite each other in the ABAP/4 memory), since it exists only for reasons of compatibility with R/2.

Effect

Imports only data stored in ABAP/4 memory under the ID key.

SY-SUBRC = 4:

The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.

Related

EXPORT TO MEMORY, FREE MEMORY

Variant 2

IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.

1. ... TO f (for each field f to be imported)
2. ... MAJOR-ID id1 (instead of ID key)
3. ... MINOR-ID id2 (together with MAJOR-ID id1)
4. ... CLIENT g (after dbtab(ar) )
5. ... USING form

Effect

Imports data objects obj1 ... objn (fields, structures, componex structures or tables) from the data cluster with ID key in area ar of the database table dbtab (see EXPORT TO DATABASE).

SY-SUBRC = 4:

The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.

TABLES INDX. 
DATA: INDXKEY LIKE INDX-SRTFD, 
	F1(4), F2 TYPE P, 
	BEGIN OF TAB3 OCCURS 10, 
		CONT(4), 
	END OF TAB3. 
 
INDXKEY = 'INDXKEY'. 
IMPORT F1 F2 TAB3 FROM DATABASE INDX(ST) ID INDXKEY.

Notes

The structure of fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. In addition, the objects must be imported under the same name used to export them. If this is not the case, either a runtime error occurs or no import takes place.
Exception: You can lengthen or shorten the last field if it is of type CHAR, or add/omit CHAR fields at the end of the structure.

Addition 3

... MINOR-ID id2 (together with MAJOR-ID id1)

Effect

Searches for a record with an ID that matches id1 in the first part (length of id1) and - if MINOR-ID id2 is also specified - is greater than or equal to id2 in the second part.

Effect

Takes the data from the client g (only with client-specific import/export databases).

Example

TABLES INDX. 
DATA F1. 
IMPORT F1 FROM DATABASE INDX(AR) CLIENT '002' ID 'TEST'.


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

Effect

Does not read the data from the database. Instead, calls the FORM routine form for each record read from the database without this addition. This routine can take the data key of the data to be retrieved from the database table work area and write the retrieved data to this work area. The name of the routine has the format <name of database table>_<name of form>; 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.


Depending on the operands or the datasets to be imported, various runtime errors may occur.


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

1. ... TO f (for each field f to be imported)

Effect

Imports data objects (fields, field strings or internal tables) from the update data. You must specify the update key assigned by the system (with current request number) as the key.

SY-SUBRC = 4:

The data objects could not be imported. An incorrect ID may have been used.
The contents of all objects remain unchanged.

Variant 4

IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.

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

Effect

Imports an object directory stored under the specified ID with EXPORT TO DATABASE into the table itab. The internal table itab may not have the type HASHED TABLE or ANY TABLE.

SY-SUBRC = 4:

The directory could not be imported, probably because an incorrect ID was used.

The internal table itab must have the same structure as the Dictionary structure CDIR ( INCLUDE STRUCTURE).

Effect

Takes data from the client g (only with client-specific import/export databases).

Example

Directory of a cluster consisting of two fields and an internal table:

TABLES INDX. 
DATA: INDXKEY LIKE INDX-SRTFD, 
	F1(4), F2 TYPE P, 
	BEGIN OF TAB3 OCCURS 10, 
		CONT(4), 
	END OF TAB3, 
	BEGIN OF DIRTAB OCCURS 10. 
		INCLUDE STRUCTURE CDIR. 
DATA  END OF DIRTAB. 
 
INDXKEY = 'INDXKEY'. 
EXPORT F1 F2 TAB3 TO 
	 DATABASE INDX(ST) ID INDXKEY.	" TAB3 has 17 entries 
... 
IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY.

Then, the table DIRTAB contains the following:

NAME OTYPE FTYPE TFILL FLENG
-----------------------------------
F1 F C 0 4
F2 F P 0 8
TAB3 T C 17 4

The meaning of the individual fields is as follows:

NAME: Name of stored object

OTYPE: Object type (F: Field, R: Field string / Dictionary structure, T: Internal table)

FTYPE: Field type (C: Character, P: Packed, ...)
Field strings and internal tables have the type C.

TFILL: Number of internal table lines filled

FLENG: Length of field in bytes
With internal tables: Length of header line.

Variant 5

IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.

Variant 6

IMPORT obj1 ... objn FROM SHARED BUFFER dbtab(ar) ID key.

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

Effect

Imports data objects obj1 ... objn (fields or tables) from the cross-transaction application buffer. The data objects are read in the application buffer using the ID key of the area ar of the buffer area for the table dbtab (see EXPORT TO SHARED BUFFER).

SY-SUBRC = 4:

The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.

Example

Import two fields and an internal table from the application 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. 
* Import data. 
IMPORT F1 F2 ITAB3 FROM 
	 SHARED BUFFER INDX(ST) ID INDXKEY. 
* After import, the data fields INDX-AEDAT and 
* INDX-USERA in front of CLUSTR are filled with 
* the values in the fields before the EXPORT 
* statement.

Notes

The structure of the fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. Moreover, the objects must be imported with the same name used to export them. If this is not the case, a runtime error occurs or no import is performed.

Effect

Takes the data from the client g (if the import/export table dbtab is client-specific).

Effect

Specifies the objects to be imported as the internal table itab. You can use this variant instead of the static object lists in the "... FROM MEMORY", "... FROM DATABASE", "... FROM DATASET" and "... FROM SHARED BUFFER " variants. You can use all of the additions from these static variants in this 'dynamic' variant. The table itab may not have the type HASHED TABLE or ANY TABLE.

The first column contains the objects names in the data cluster (corresponds to obj1 ...objn in the static case). The second column contains the name in the program if this is different (corresponding to the field f in the FROM f addition). If the table only has one column, or the second column only contains blanks, this corresponds to a static IMPORT without a TO addition. In any case, the first column of the table (and the second, if applicable) should have the 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. 
 
IMPORT (OBJ_TAB) FROM MEMORY ID 'ABCD'. 

The dynamic EXPORT statement corresponds to the static IMPORT statement

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

This imports the field A into field A, the internal table B into internal table B_PROG and the structure C into structure C_PROG.

Note

Runtime errors:

SY-SUBRC is set in exactly the same way as in a static IMPORT.