Get Example source ABAP code based on a different SAP table
ARTICLE
Syntax revisions in Data clusters ABAP Code Snippet ARTICLE
You Must Declare Identification In ABAP Objects, the ID addition must be declared in IMPORT/EXPORT/FREE ... MEMORY statements.
In ABAP Objects, the following statements cause an error message:
EXPORT f TO MEMORY. IMPORT f FROM MEMORY. FREE MEMORY.
Correct syntax:
EXPORT f TO MEMORY ID key. IMPORT f FROM MEMORY ID key. FREE MEMORY ID key.
Cause:
Without identification, all programs in a call chain run in the same memory area. This leads to unpredictable results, particularly when complex transactions are being performed. ABAP Code Snippet ABAP Code Snippet ARTICLE
Cannot Use Generic Identification You cannot use the MAJOR-ID and MINOR-ID additions when reading data clusters from database tables in ABAP Objects.
In ABAP Objects, the following statements cause an error message:
IMPORT ... FROM DATABASE dbtab(ar) ... MAJOR-ID maid
[MINOR-ID miid].
Correct syntax:
IMPORT ... FROM DATABASE dbtab(ar) ID id.
Cause:
The identification in the statement must be unique. If necessary, you must program the logic of the MAJOR-ID and MINOR-ID additions yourself. ABAP Code Snippet ABAP Code Snippet ARTICLE
Cannot Use Implicit Names in Clusters In ABAP Objects, you must declare explicit names when importing and exporting data clusters, preferably using the equals sign (=), rather than the old FROM and TO additions.
In ABAP Objects, the following statements cause an error message:
EXPORT f1 ... fn TO ... IMPORT f1 ... fn FROM ...
Correct syntax:
EXPORT name1 = f1 ... namen = fn TO ... IMPORT name1 = f1 ... namen = fn FROM ...
or
EXPORT name1 FROM f1 ... namen FROM fn TO ... IMPORT name1 TO f1 ... namen TO fn FROM ...
Cause:
Using implicit names is a source of error. The names declared are to be understood as identification for the fields in the cluster. When the implicit method of exporting is used, the system uses exactly the names declared, that is including any offset/length declarations or selector prefixes. When the cluster is imported in another context, these names must be known and identically declared. Using the equals sign (=) emphasizes the fact that formal parameters are to the left of the symbol and actual parameters to the right - similar to how it is used in method and function module calls. The FROM and TO expressions are needed to declare the data repository. ABAP Code Snippet ABAP Code Snippet ARTICLE
No Use of Table Work Areas If user data fields are to be transported to or from cluster databases or the cross-transaction application buffer, the addition FROM|TO wa must be specified with the statements EXPORT/IMPORT ... TO/FROM DATABASE/SHARED BUFFER in ABAP Objects.
The following cannot be used in ABAP Objects:
dbtab-... = ...
EXPORT ... TO DATABASE dbtab(ar) ID id. EXPORT ... TO SHARED BUFFER dbtab(ar) ID id.
IMPORT ... FROM DATABASE dbtab(ar) ID id. IMPORT ... FROM SHARED BUFFER dbtab(ar) ID id.
... = dbtab-
Correct syntax:
DATA wa TYPE dbtab.
wa-... = ...
EXPORT ... TO DATABASE dbtab(ar) ID id FROM wa. EXPORT ... TO SHARED BUFFER dbtab(ar) ID id FROM wa.
IMPORT ... FROM DATABASE dbtab(ar) ID id TO wa. IMPORT ... FROM SHARED BUFFER dbtab(ar) ID id TO wa.
... = wa-...
Reason:
If the addition FROM|TO wa is not specified, the system tries to transport the user data fields of the table work area declared by TABLES. If the table work area is not found, the user data fields are not transported. A table work area can be declared in the main program of local classes; however, it should not be used. In global classes the table work area cannot be used at all. ABAP Code Snippet ABAP Code Snippet ARTICLE
No Clusters in Files Exporting and importing of file clusters to and from files on the application server is not yet possible in ABAP Objects.
Error message in ABAP Objects if the following syntax is used:
EXPORT ... TO DATASET ... IMPORT ... FROM DATASET ...
Reason:
These statements are no longer supported. ABAP Code Snippet
