Data Clusters

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.

Cannot Use Generic Identification

You cannot use the MAJOR-ID and MINOR-ID additions when reading cluster databases 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 programthe logic of the MAJOR-ID and additions yourself.

Cannot Use Implicit Names in Clusters

In ABAP Objects, you must declare explicit names when importing and exporting data clusters, preferably using the equals symbol (=), rather than the old FROM and TO additions.

In ABAP Objects, the following statments 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 equal symbol (=) 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.

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.

No clusters in files

Exporting and importing of file clusters to and from files on the application server has 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.