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

IMPORT - medium

Short 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 be imported can be taken from an elementary data object xstr, an internal table itab, the ABAP Memory, a database table dbtab, or a cross-program memory area (if SHARED MEMORY or BUFFER 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.

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 which was generated using the INTERNAL TABLE addition of the EXPORT statement; otherwise, a runtime error occurs. Note that the internal table cannot be empty.

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.

Alternative 4

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

Effect

If DATABASE is specified, the data cluster that was written to the database table dbtab in the area ar and under the ID specified in id using the statement EXPORT is imported. The database 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 database 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 database 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

• 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.
• Since each client represents a self-contained unit, the addition CLIENT must not be used in application programs.
• In addition, outside of classes, the specification id can be replaced by the obsolete specification obs_id.
  

Example

The table that is imported into the internal table itab is the table exported under the name tab and the ID "TABLE" into the area "SQ" of the database table DEMO_INDX_TABLE (refer to the additions medium of the statement EXPORT). However, the components (which can be selected as required) are assigned to the structure wa_indx.

TYPES: 
  BEGIN OF tab, 
    col1 TYPE i, 
    col2 TYPE i, 
  END OF tab. 

DATA: 
  wa_indx TYPE demo_indx_table, 
  itab    TYPE STANDARD TABLE OF tab. 

IMPORT tab = itab 
  FROM DATABASE demo_indx_table(SQ) 
  TO   wa_indx 
  ID 'TABLE'. 

cl_demo_output=>write_data( wa_indx-timestamp ). 
cl_demo_output=>write_data( wa_indx-userid ). 
cl_demo_output=>display_data( 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 a database table dbtab. The set-up 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 INDX-like 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, we recommend that shared objects are used. Shared objects enable objects with complex dependencies to be saved, can be processed like normal objects, and enable multiple users to access the shared memory without any copying effort.