1. IMPORT
obj1 ... objn FROM DATA BUFFER f.
2. IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
2.
IMPORT obj1 ... objn FROM MEMORY.
3. IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
4. IMPORT
obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
5. IMPORT
obj1 ... objn FROM DATABASE dbtab(ar) ID key.
6. IMPORT
obj1 ... objn FROM DATASET dsn(ar) ID key.
7.
IMPORT obj1 ... objn FROM LOGFILE ID key.
8. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
9. IMPORT (itab) FROM ... .
In some cases, the syntax rules that apply to Unicode programs are different
than those for non-Unicode programs. For more details, see Storing Cluster Tables.
IMPORT obj1 ... objn FROM DATA BUFFER f.
1. ... =
f (for each object to be imported)
2.
... TO f (for each object to be imported)
3.
... ACCEPTING PADDING
4.
... ACCEPTING TRUNCATION
5.
... IGNORING STRUCTURE BOUNDARIES
6.
... IGNORING CONVERSION ERRORS
7.
... REPLACEMENT CHARACTER c
8.
... IN CHAR-TO-HEX MODE
9.
... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters.
Imports the data objects obj1 ... objn from the data buffer
declared. The data buffer must be of type XSTRING . The
data objects obj1 ... objn can be fields, structures,
complex structures, or tables. The system imports all the data that has been stored in the data buffer
f using the EXPORT
... TO DATA BUFFER statement and is listed here. It also checks that the structure used
in the
IMPORT statement matches the one in the EXPORT statement.
The Return Code is set as follows:
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is stored in the field f.
... ACCEPTING PADDING
This addition allows you to append new fields to the end
of structures, sub-structures,
and internal tables. The IMPORT statement fills the additional
fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type
fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
... ACCEPTING TRUNCATION
This addition allows you to shorten the last CHAR
fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
... IGNORING STRUCTURE BOUNDARIES
This addition means that only the fragment sequence is
relevant - that is, that any sub-structures
match. If you use this addition, the system ignores any alignment changes necessitated by Unicode -
such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure)
or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be
ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system
can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
...IGNORING CONVERSION ERRORS
This addition prevents the system from triggering a
runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
... REPLACEMENT CHARACTER c
The replacement character is used if a particular
character cannot be converted when the character set is converted.
This addition can only be used in conjunction with addition 6.
... IN CHAR-TO-HEX MODE
Not all character-type fields are converted. To convert
a field, you must create a field
(or structure) that is identical to the exported field or structure, except that all its character-type
components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs,
to allow you to import camouflaged binary data as single-byte characters.
Moreover, you cannot use this addition in conjunction with the additions 3, 4, 5, 6, or 7.
... CODE PAGE INTO f1
The code page of the exported data is stored in the
character-type field f1 - for example, to
analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
... ENDIAN INTO f2
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 -
for example, to analyze data that has been imported with the IN CHAR-TO-HEX
MODE addition. The field f2 must have the type
ABAP_ENDIAN, which is defined in the type group ABAP.
For this reason, the type group ABAP must be included
in the ABAP program using a TYPE-POOLS statement.
IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
1. ...
= f (for each object to be imported)
2.
... TO f (for each object to be imported)
3.
... ACCEPTING PADDING
4.
... ACCEPTING TRUNCATION
5.
... IGNORING STRUCTURE BOUNDARIES
6.
... IGNORING CONVERSION ERRORS
7.
... REPLACEMENT CHARACTER c
8.
... IN CHAR-TO-HEX MODE
9.
... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See No implicit field names in cluster.
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from the specified internal table itab. The first column in the internal table must be of the predefined type INT2 and the second must be type X. To define the first column you must refer to a data element in the ABAP Dictionary that has the predefined type INT2.
All data that was stored in the internal table itab using
EXPORT ... TO INTERNAL TABLE
and listed, is imported. The system checks that the EXPORT
and IMPORT structures match.
The Return Code is set as follows:
... = f (for each object to be imported)
... TO f (for each object to be imported)
Places the object in the field f.
... ACCEPTING PADDING
This addition allows you to add new fields to the ends
of structures, even to substructures
and internal tables (the additional fields are filled with initial value during the
IMPORT). It also allows you to increase the size of existing
fields (C, N, X, P, I1, and I2) and to map Char fields to STRING type fields or byte fields to XSTRING type fields.
... ACCEPTING TRUNCATION
This addition allows you to shorten the last CHAR
field or omit the last component on the highest level (till Release 4.6 this was possible without specifying an addition).
... IGNORING STRUCTURE BOUNDARIES
This addition means that only the page order is
relevant, that is any substructures
match. With this addition, the system also ignores alignment changes arising from the Unicode conversion
(for example, due to subsequent insertion of named includes).
This addition rules out any subsequent
structural enhancements (addition 3) or structural shortening (addition 4) because with this addition
it is the structural limits and include limits that are to be ignored.
As from Release 6.10, the
include information will also be stored in the dataset, so that it is possible to also check whether
the includes match, that is substructures and includes (named or unnamed) are treated the same. When importing data that was exported in a Release lower than 6.10, the includes are not checked.
...IGNORING CONVERSION ERRORS
This addition has the effect that an error in the
character set conversion does not cause a runtime error. The system uses "#" as a replacement character.
... REPLACEMENT CHARACTER c
The system uses the specified replacement character if a
character cannot be converted
during a character set conversion. If this addition is not specified, the system uses "#" as a replacement character.
This addition can only be used in conjunction with addition 6.
... IN CHAR-TO-HEX MODE
No character type fields are converted. For this you
must create a field or structure
that is identical to the exported field or exported structure, except that all character type fields
must be replaced with hexadecimal fields.
This addition, which is only allowed in programs with
a set Unicode flag, allows you to import binary data disguised as single byte characters. This addition cannot be used in conjunction with additions 3, 4, 5, 6, and 7.
... CODE PAGE INTO f1
The codepage of the exported data is stored in the
character-type field f1 (for example, to be
able to analyze the data imported with the addition IN CHAR-TO-HEX MODE).
... ENDIAN INTO f2
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 (for
example, to be able analyze the data imported using the addition IN
CHAR-TO-HEX MODE). The field f2 must be of
type ABAP_ENDIAN, defined in type group ABAP. You must
therefore include the type group ABAP in the ABAP program with a TYPE-POOLS statement.
IMPORT obj1 ... objn FROM MEMORY.
1.
... = f (for each object to be imported) 2. ... TO
f (for each object to be imported)
3. ... ID key
4.
... ACCEPTING PADDING
5. ... ACCEPTING TRUNCATION
6. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See You Must Enter Identification and Cannot Use Implicit Field Names inClusters
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.
The Return Code is set as follows:
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is placed in field f.
... ID key
Imports only data stored in ABAP memory under the ID key.
The key, key, must be a character-type
data object (but not a string).
The Return Code is set as follows:
... ACCEPTING PADDING
This addition allows you to append new fields to the end of structures, sub-structures, and internal
tables. The IMPORT statement fills the additional fields
with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields
to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
... ACCEPTING TRUNCATION
This addition allows you to shorten the last CHAR field,
or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
... IGNORING STRUCTURE BOUNDARIES
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match.
If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as
inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure)
or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be
ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system
can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
EXPORT TO MEMORY,
DELETE FROM MEMORY, FREE MEMORY
IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
1. ... = f (for each object to be exported) 2.
... TO f (for each object to be exported)
3. ...
CLIENT g
(before ID key)
4. ...
TO wa
(after itab(ar) or ID
key
)
5.
... ACCEPTING PADDING
6. ... ACCEPTING TRUNCATION
7. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See
You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.
Imports the data objects obj1 ... objn (fields, structures,
complex structures, or tables) from shared memory. The data objects are read using the
ID key from the area ar
in the table
itab - c.f. EXPORT
TO SHARED MEMORY). You must use itab to specify a database table although the system reads from a memory table with the appropriate structure.
The Return Code is set as follows:
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is stored in the field f.
... CLIENT g (before ID key)
The data is imported from client g (provided the import/export
table is
tab client-specific). The client, g must be a character-type data object (but not a string).
... TO wa (after itab(ar) or ID key)
You need to use this addition if user data fields have been stored in the application buffer and are
to be read from there. The work area wa is used instead
of the table work area. The target area must correspond to the structure of the called table tab.
... ACCEPTING PADDING
This addition allows you to: append new fields to the end of structures, sub-structures, and internal
tables. The IMPORT statement fills the additional fields
with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields
to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
... ACCEPTING TRUNCATION
This addition allows you to shorten the last CHAR fields,
or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
... IGNORING STRUCTURE BOUNDARIES
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match.
If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as
inserting named includes.
You cannot use this addition with either addition 4 (enlarge structure)
or addition 5 (shorten structure), since it specifies that structure and include boundaries are to be
ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system
can also check that includes match - that is, that sub-structures and includes (named or unnamed) are
treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO SHARED
MEMORY, DELETE FROM SHARED MEMORY
IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
1. ... = f (for each object to be exported) 2.
... TO f (for each object to be exported)
3. ...
CLIENT g
(before ID key)
4. ... TO wa (last addition or after itab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See
Cannot Use Implicit Fieldnames in Clusters und Cannot Use Table Work Areas.
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 itab (see
EXPORT TO SHARED BUFFER).
You must use dbtab to specify a database table although the system reads from a memory table with an appropriate structure.
The Return Code is set as follows:
Import two fields and an internal table from the application buffer with the structure INDX:
TYPES: BEGIN OF ITAB3_LINE,
CONT(4),
END OF ITAB3_LINE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
F1(4),
F2(8) TYPE P DECIMALS 0,
ITAB3
TYPE STANDARD TABLE OF ITAB3_LINE,
INDX_WA TYPE INDX.
*
Import data.
IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3
FROM
SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.
* 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.
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is placed in the field f
... CLIENT g (after dbtab(ar))
Takes the data from the client g (if the import/export
table
dbtab is client-specific). The client g must be a character-type data object (but not a string).
... TO wa (as the last addition or after itab(ar))
You need to use this addition if you want to save user data fields in the application buffer and then
read them from there later. The system uses a work area wa
instead of a table work area. The target area must have the same structure as the table tab.
DATA: INDX_WA TYPE INDX,
F1.
IMPORT F1 = F1 FROM SHARED
BUFFER INDX(AR)
CLIENT '001' ID 'TEST'
TO INDX_WA.
WRITE: / 'AEDAT:', INDX_WA-AEDAT,
/ 'USERA:', INDX_WA-USERA,
/ 'PGMID:', INDX_WA-PGMID.
IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3.
... CLIENT g (before ID
key
)
4. ... USING form
5. ...
TO wa (last addition or after dbtab(ar))
6.
... MAJOR-ID id1 (instead of ID key)
7.
... MINOR-ID id2 (with MAJOR-ID
id1
)
8.
... ACCEPTING PADDING
9. ... ACCEPTING TRUNCATION
10. ...
IGNORING STRUCTURE BOUNDARIES
11. ... IGNORING
CONVERSION ERRORS
12. ... REPLACEMENT CHARACTER c
13.
... IN CHAR-TO-HEX MODE
14. ... CODE PAGE INTO f1
15. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Fieldnames in Clusters and Cannot Use Table Work Areas.
Imports data objects obj1 ... objn (fields, structures,
complex structures, or tables) from the
data cluster
with ID key in area ar
of the database table
dbtab (see EXPORT TO DATABASE).
The Return Code is set as follows:
Import two fields and an internal table:
TYPES: BEGIN OF TAB3_TYPE,
CONT(4),
END OF TAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4),
F2 TYPE P,
TAB3 TYPE STANDARD TABLE OF TAB3_TYPE WITH
NON-UNIQUE DEFAULT
KEY,
WA_INDX TYPE INDX.
INDXKEY = 'INDXKEY'.
IMPORT
F1 = F1
F2 = F2
TAB3 = TAB3 FROM DATABASE INDX(ST) ID INDXKEY
TO WA_INDX.
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is placed in field f.
... CLIENT g (before the ID key)
Data is taken from the client g (in client-specific import/export
databases only). Client g must be a character-type data object (but not a string).
DATA: F1,
WA_INDX TYPE INDX.
IMPORT F1 = F1 FROM DATABASE
INDX(AR) CLIENT '002' ID 'TEST'
TO WA_INDX.
... USING form
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
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.
... TO wa (after key or after dbtab(ar))
You need to use this addition if you want to save user data fields in the cluster database and then
read from there. The system uses the work area wa instead
of a table work area. The target area entered must have the same structure as the table dbtab.
DATA WA LIKE INDX.
DATA F1.
IMPORT F1 = F1 FROM DATABASE INDX(AR)
CLIENT '002' ID 'TEST'
TO WA.
WRITE: / 'AEDAT:', WA-AEDAT,
/ 'USERA:', WA-USERA,
/ 'PGMID:', WA-PGMID.
... MAJOR-ID id1 (instead of the ID key).
... MINOR-ID id2 (with MAJOR-ID id1)
This addition is not allowed in an ABAP Objects context. See Cannot Use Generic Identification.
Searches for a record the first part of whose ID (length
of id1) matches id1
and whose second part - if MINOR-ID id2 is also declared - is greater than or equal to id2.
... ACCEPTING PADDING
This addition allows you to append new fields to the end of structures, sub-structures, and internal
tables. The IMPORT statement fills the additional fields
with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields
to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
... ACCEPTING TRUNCATION
This addition allows you to shorten the last CHAR fields,
or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
... IGNORING STRUCTURE BOUNDARIES
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match.
If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as
inserting named includes.
You cannot use this addition with either addition 8 (enlarge structure)
or addition 9 (shorten structure), since it specifies that structure and include boundaries are to be
ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system
can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
...IGNORING CONVERSION ERRORS
This addition prevents the system from triggering a runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
... REPLACEMENT CHARACTER c
The replacement character is used if a particular character cannot be converted when the character set
is converted. If you do not use this addition, '#' is used as a replacement character.
This addition can only be used in conjunction with addition 11.
... IN CHAR-TO-HEX MODE
All character-type fields are not converted. To convert a field, you must create a field (or structure)
that is identical to the exported field or structure, except that all its character-type components
must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to
allow you to import camouflaged binary data as single-byte characters. Moreover, you cannot use this addition in conjunction with the additions 8, 9, 10, 11, and 12.
... CODE PAGE INTO f1
The code page of the exported data is stored in the character-type field
f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
... ENDIAN INTO f2
The byte order(LITTLE or BIG) of the exported data is stored in the field
f2 - for example, to analyze data that has been imported
with the
IN CHAR-TO-HEX MODE addition. The field f2
must have the type ABAP_ENDIAN, which is defined in the type group ABAP.
For this reason, the type group ABAP must be included
in the ABAP program using a TYPE-POOLS statement.
IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
This variant is not allowed in an ABAP Objects context. See Cannot Use Clusters in Files
IMPORT obj1 ... objn FROM LOGFILE ID key.
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
1.
... = f (for each field f
to be imported) 2. ... TO f (for each field f to be imported)
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters
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.
The key, key,
must be a character-type data object (but not a string).
The Return Code is set as follows:
... = f (for each object to be imported)
... TO f (for each object to be imported)
The object is placed in field f.
IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
1. ... CLIENT g (after dbtab(ar))
2. ... TO wa (last addition or after dbtab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Table Work Areas.
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.
The key, key, must be a character-type
data object (but not a string).
The Return Code is set as follows:
... CLIENT g (before ID key)
Takes data from the client g (only with client-specific
import/export databases). Client g must be a character-type data object (but not a string).
... TO wa (last addition or after dbtab(ar))
Uses the work area wa instead of the table work area.
When you use this addition, you do not need to declare the table dbtab,
named after
DATABASE using a TABLES
statement. The work area entered must have the same structure as the table dbtab.
Directory of a cluster consisting of two fields and an internal table:
TYPES: BEGIN OF TAB3_LINE,
CONT(4),
END OF TAB3_LINE,
BEGIN OF DIRTAB_LINE.
INCLUDE STRUCTURE CDIR.
TYPES END OF DIRTAB_LINE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4),
F2(8)
TYPE P decimals 0,
TAB3 TYPE STANDARD
TABLE OF TAB3_LINE,
DIRTAB TYPE STANDARD TABLE OF
DIRTAB_LINE,
INDX_WA TYPE INDX.
INDXKEY = 'INDXKEY'.
EXPORT F1 = F1
F2 = F2
TAB3 = TAB3
TO DATABASE INDX(ST) ID INDXKEY " TAB3 has 17 entries
FROM INDX_WA.
...
IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY
TO INDX_WA.
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:
IMPORT (itab) FROM ... .
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 DATA BUFFER
", "... FROM MEMORY", "...
FROM SHARED MEMORY",
"... FROM SHARED BUFFER",
"
... FROM DATABASE", and "...
FROM DATASET" 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.
Structure of the internal table itab:
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 CHAR or STRING.
TYPES: BEGIN OF OBJ_LINE,
CLUSTERNAME(30),
PROGRAMNAME(10),
END OF OBJ_LINE,
BEGIN
OF B_LINE,
FIELD_1 TYPE I,
FIELD_2(1) TYPE N,
END
OF B_LINE.
DATA: OBJ_TAB TYPE STANDARD TABLE OF OBJ_LINE,
OBJ_WA TYPE
OBJ_LINE,
B_PROG TYPE STANDARD TABLE OF B_LINE,
B_WA TYPE
B_LINE,
A(10),
C_PROG
LIKE SYST.
MOVE: 'A' TO OBJ_WA-CLUSTERNAME.
APPEND OBJ_WA
TO OBJ_TAB. CLEAR OBJ_WA.
MOVE: 'B' TO OBJ_WA-CLUSTERNAME,
'B_PROG' TO OBJ_WA-PROGRAMNAME.
APPEND OBJ_WA TO OBJ_TAB.
CLEAR OBJ_WA.
MOVE: 'C' TO OBJ_WA-CLUSTERNAME,
'C_PROG' TO OBJ_WA-PROGRAMNAME.
APPEND OBJ_WA TO OBJ_TAB. CLEAR OBJ_WA.
IMPORT (OBJ_TAB) FROM MEMORY ID 'ABCD'.
The dynamic EXPORT statement corresponds to the static IMPORT statement
IMPORT A = A B = B_PROG C = 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.
The Return Code is set as follows:
SY-SUBRC is set in exactly the same way as in a static IMPORT.
The exceptions of the statement IMPORT are described in
IMPORT Exceptions.
Reading Data Objects from Memory
Creating a Table of Contents for a Data Cluster
Reading Data Objects from a Cluster Database