Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Processing External Data →  Data Cluster →  IMPORT 

IMPORT - medium

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... { DATA BUFFER xstr } 

  | { INTERNAL TABLE itab } 

  | { MEMORY ID id } 

  | { DATABASE      dbtab(ar) [TO wa] [CLIENT cl] ID id } 

  | { SHARED MEMORY dbtab(ar) [TO wa] [CLIENT cl] ID id } 

  | { SHARED BUFFER dbtab(ar) [TO wa] [CLIENT cl] ID id } ...

Alternatives

1. ... DATA BUFFER xstr

2. ... INTERNAL TABLE itab

3. ... MEMORY ID id

4. ... DATABASE dbtab(ar) [TO wa] [CLIENT cl] ID id

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

6. ... SHARED BUFFER dbtab(ar) [TO wa] [CLIENT cl] ID id

Effect

The data cluster to import can be taken from an elementary data object xstr or an internal table itab , the ABAP Memory, a database table dbtab, or a cross-program memory area (if SHARED MEMORY or BUFFER is specified) .

Alternative 1

... DATA BUFFER xstr

Effect

If DATA BUFFER is specified, the data cluster is taken from the elementary data object xstr, which must be of the type xstring. The data object must contain a data cluster which was created using the DATA BUFFER addition of the EXPORT statement. Otherwise, a runtime error occurs. Note that the data object cannot be initial.


Example

See the example for the addition DATA BUFFER of the statement EXPORT.

Alternative 2

... INTERNAL TABLE itab

Effect

If INTERNAL TABLE is specified, the data cluster is taken from the internal table itab. The first column of itab must have the data type s or i and the second column must have the type x. The only table category allowed for itab are standard tables without secondary table keys. The internal table must contain a data cluster created using the INTERNAL TABLE addition of the EXPORT statement; otherwise, a runtime error occurs. Note that the internal table cannot be empty.


Example

See the example for the addition INTERNAL TABLE of the statement EXPORT.

Alternative 3

... MEMORY ID id

Effect

If MEMORY is specified, the data cluster that was written to the ABAP Memory under the ID specified in id by the statement EXPORT is imported. id expects a flat character-like data object. This object contains the ID of the data cluster, which is case-sensitive.


Note

Outside of classes, an obsolete short form exists, in which the addition ID can be omitted. This reads the data cluster saved by the statement EXPORT without an ID being specified.


Example

See the example for the addition MEMORY ID of the statement EXPORT.

Alternative 4

... DATABASE dbtab(ar) [TO wa] [CLIENT cl] ID id

Effect

If DATABASE is specified, the data cluster that was written to the export/import table dbtab in the area ar and under the ID specified in id using the statement EXPORT is imported. The export/import table dbtab must be set up in the same way as described for the EXPORT statement. id expects a flat, character-like data object that contains the ID of the data cluster, which is case-sensitive. The two-character area ar must be specified directly.

After TO, a work area wa that has the same data type as the database table dbtab can be specified. When imported, the values of the database fields that are between the fields SRTF2 and CLUSTR are assigned to the components of wa with the same name. If the addition TO wa is not specified within classes, no data transport takes place in these components. If the addition TO 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 values of these database fields are assigned, when imported, to the components of the table work area dbtab with the same names.

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.


Notes

  • Since each client represents a self-contained unit, the addition CLIENT must not be used in application programs.
  • It is still possible to use a table work area implicitly outside of classes (instead of using TO wa explicitly). This should be considered an obsolete short form, however.
  • Only outside of classes can id still be replaced by the obsolete obs_id.


Example

Reads the table exported under the name scarr_tab and the ID SCARR into the area SC of the database table DEMO_INDX_BLOB (see the example for the addition DATABASE of the statement EXPORT) into the internal table itab. Here, those components that can be selected are assigned to the structure wa.

DATA: 
  wa   TYPE demo_indx_blob, 
  itab TYPE table OF scarr with EMPTY KEY. 

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

cl_demo_output=>new( 
 )->write_data( wa-timestamp 
 )->write_data( wa-userid 
 )->display( itab ).

Alternative 5

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

Alternative 6

... SHARED BUFFER dbtab(ar) [TO wa] [CLIENT cl] ID id

Effect

If SHARED MEMORY or SHARED BUFFER is specified, the data cluster is imported that was written (by the statement EXPORT) to the relevant application buffer of the shared memory in the area ar and using the ID specified in id. The system accesses a memory table of the application buffer whose row structure is defined by an export/import table dbtab. The setup of this table is described in the statement EXPORT. id expects a flat character-like data object that contains the ID of the data cluster. The two-character area ar must be specified directly.

For the optional work area wa and client cl, the same applies as for imports from a database table.


Notes

  • The length of the key fields of the export/import table specified between the columns RELID and SRTF2 cannot exceed 59 or 62 characters, depending on whether a client column exists.
  • Instead of using data clusters in the shared memory, it is best to use shared objects. Shared objects make it possible to store objects with complex dependencies, can be processed like normal objects, and enable multiple users to access the shared memory without any copying effort.


Example

Reads the table exported under the name scarr_tab and the ID SCARR into the area SC of the cross-transaction application buffer (see the example for the addition SHARED BUFFER of the statement EXPORT) into the internal table itab. Here, those components that can be selected are assigned to the structure wa.

DATA: 
  wa   TYPE demo_indx_blob, 
  itab TYPE table OF scarr with EMPTY KEY. 

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

cl_demo_output=>new( 
 )->write_data( wa-timestamp 
 )->write_data( wa-userid 
 )->display( itab ).