Get Example source ABAP code based on a different SAP table
• DATA BUFFER IMPORT cluster • INTERNAL TABLE IMPORT cluster • MEMORY IMPORT cluster • ID IMPORT FROM MEMORY • DATABASE IMPORT cluster • TO IMPORT FROM DATABASE • CLIENT IMPORT FROM DATABASE • ID IMPORT FROM DATABASE • SHARED MEMORY IMPORT cluster • TO IMPORT FROM SHARED MEMORY • CLIENT IMPORT FROM SHARED MEMORY • ID IMPORT FROM SHARED MEMORY • SHARED BUFFER IMPORT cluster • TO IMPORT FROM SHARED BUFFER • CLIENT IMPORT FROM SHARED BUFFER • ID IMPORT FROM SHARED BUFFER
IMPORT>, medium> Short Reference >
ABAP_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 $} ... >
ABAP_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>
What does it do? The data cluster> to be imported can be taken from an elementary data object xstr> or an internal table itab > BEGIN_SECTION VERSION 5 OUT , the ABAP Memory>, a database table dbtab>, or a cross-program memory area (SHARED MEMORY> or BUFFER> specified) END_SECTION VERSION 5 OUT .
ABAP Alternative 1 ... DATA BUFFER xstr> BEGIN_SECTION ID IMPORT-DATA-BUFFER
What does it do? 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 that was created using the DATA BUFFER> addition of the EXPORT>> statement. Otherwise, a runtime error> occurs. The data object must not be initial.
ABAP_EXAMPLE_VX5 See the example for the addition DATA BUFFER>> of the statement EXPORT>. ABAP_EXAMPLE_END END_SECTION ID IMPORT-DATA-BUFFER
ABAP Alternative 2 ... INTERNAL TABLE itab> BEGIN_SECTION ID IMPORT-ITAB
What does it do? 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. The internal table must not be empty.
ABAP_EXAMPLE_VX5 See the example for the addition INTERNAL TABLE>> of the statement EXPORT>. ABAP_EXAMPLE_END END_SECTION ID IMPORT-ITAB
ABAP Alternative 3 ... MEMORY ID id> BEGIN_SECTION ID IMPORT-MEMORY
What does it do? 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.
Latest notes: NON_V5_HINTS Outside of classes, an obsolete short form> exists, in which the addition ID> can be omitted. This reads the data cluster stored using the statement EXPORT>> without specifying an ID. ABAP_HINT_END
Example ABAP Coding
See the example for the addition MEMORY ID>> of the statement EXPORT>. ABAP_EXAMPLE_END END_SECTION ID IMPORT-MEMORY
ABAP Alternative 4 ... DATABASE dbtab(ar) $[TO wa$] $[CLIENT cl$] ID id> BEGIN_SECTION ID IMPORT-DATABASE
What does it do? 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 structured> as described in 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 to the components of the table work area dbtab> with the same names during the import. If the export/import table dbtab> is client-dependent, 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.
Latest notes:
Since each client represents a self-contained unit, the addition CLIENT> should not be used in application programs. NON_V5_HINTS
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 specification obs_id>>.
The statement IMPORT ... FROM DATABASE> does not support table buffering>. ABAP_HINT_END
Example ABAP Coding
Reading of 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, the freely selectable components are assigned to the structure wa >. ABEXA 00325 ABAP_EXAMPLE_END END_SECTION ID IMPORT-DATABASE
ABAP Alternative 5 ... SHARED MEMORY dbtab(ar) $[TO wa$] $[CLIENT cl$] ID id>
ABAP Alternative 6 ... SHARED BUFFER dbtab(ar) $[TO wa$] $[CLIENT cl$] ID id> BEGIN_SECTION ID IMPORT-SHARED
What does it do? If SHARED MEMORY> or SHARED BUFFER> is specified, the data cluster is imported that was written to the relevant application buffer of the shared memory> using the statement EXPORT>> 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 specification of the work area wa> and client cl>, the same applies as to imports from a database table.
Latest notes:
The length of the key fields of the export/import table defined between the columns RELID>> and SRTF2>> must not 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 regular objects, and enable multiple users to access the shared memory without any copying effort. NON_V5_HINTS ABAP_HINT_END
Example ABAP Coding
Reading of 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, the freely selectable components are assigned to the structure wa>. ABEXA 00326 ABAP_EXAMPLE_END END_SECTION ID IMPORT-SHARED