import from DATABASE

Former Member · ‎2004 Sep 09

Can any one explain me how the following import statement

works.

IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.

Former Member · ‎2004 Sep 09

See SAP Library:

Basis Components->ABAP Programming

The ABAP Programming Language->Saving Data Externally

->Data Clusters in the Database->Reading Data Objects From Cluster Databases

Former Member · ‎2004 Sep 09

Hi Kaushik,

With this statement you can import the data objects which are saved in the cluster database table 'dbtab' in area 'ar' under key 'key'. The data objects must be exported to the cluster database table before from another or the same program. You can have a look at the structure of the table 'INDX' to understand the structures of cluster database tables.

Regards,

Sükrü

ssimsekler · ‎2004 Sep 09

Hi

Here is the URL:

http://help.sap.com/saphelp_47x200/helpdata/en/fc/eb3bf8358411d1829f0000e829fbfe/frameset.htm

If it is not available here's a summary:

You can store data clusters in special databases in the ABAP Dictionary.

This method allows you to store complex data objects with deep structures in a single step, without having to adjust them to conform to the flat structure of a relational database. Your data objects are then available systemwide to every user. To read these objects from the database successfully, you must know their data types.

Structure of a Cluster Database

The rules for the structure of a cluster database are listed below. The fields listed in steps 1 to 4 must be created as key fields. The data types listed are ABAP Dictionary types.

If the table is client-dependent, the first field must have the name MANDT, type CHAR, and length 3 bytes. It is used for the client number. The system fills the MANDT field when you save a data cluster - either automatically with the current client or with a client that you explicitly specify in the EXPORT statement.

The next field (the first field in the case of client-independent tables) must have the name RELID, type CHAR, and length 2 bytes. This contains an area ID. Cluster databases are divided into different areas. The system fills the field RELID with the area ID specified in the EXPORT statement when it saves a data cluster.

The next field has type CHAR and variable length. It contains the name <key> of the cluster, specified in the program with the addition ID in the EXPORT statement. Since the next field is aligned, the system may fill out the field RELID with up to three unused bytes. When you create your own cluster databases, you should plan for the length of this field.

The next field must have the name SRTF2, the type INT4, and length 4. Single data clusters can extend over several lines of the database table. Theoretically, up to 2*31 lines are possible. The field SRTF2 contains the current line number within the data cluster. Its value can be from 0 to 2*31 -1. The field is filled automatically by the system when you save a data cluster (see step 7).

After SRTF2, you can include any number of user data fields of any name and type. The system does not automatically fill these fields when you save a cluster. Instead, you must assign values to them explicitly in the program before the EXPORT statement. These fields normally contain administrative information such as program name and user ID.

The penultimate field of a line must have the name CLUSTR and the type INT2 with length 2. This contains the length of the data in the following field CLUSTD. The field is filled automatically by the system when you save a data cluster.

The last field in the line must have the name CLUSTD and the type VARC. You can define it with any length. It is usually around 1000 bytes long. This is the field in which the system saves the actual data in the data cluster. The data is saved in compressed form. If CLUSTD is not long enough to accommodate a data cluster, it is split across two or more lines. The lines are numbered in field SRTF2 (see step 4).

Saving Data Objects in Cluster Databases:

EXPORT <f1> [FROM <g 1>] <f 2> [FROM <g 2>] ...

TO DATABASE <dbtab>(<ar>) [CLIENT <cli>] ID <key>.

This statement stores the data objects specified in the list as a cluster in the cluster database <dbtab>. You must declare <dbtab> using a TABLES statement. If you do not use the option FROM <f i >, the data object <f i > is saved under its own name. If you use the FROM <g i > option, the data objet <g i > is saved under the name <f i >.

<ar> is the two-character area ID for the cluster in the database

The name <key> identifies the data in the database. Its maximum length depends on the length of the name field in <dbtab>.

The CLIENT <cli> option allows you to disable the automatic client handling of a client-specific cluster database, and specify the client yourself. The addition must always come directly after the name of the database.

The EXPORT statement also transports the contents of the user fields of the table work area <dbtab> into the database table. You can fill these fields yourself beforehand.

Reading Data Objects From Cluster Databases:

IMPORT <f1> [TO <g 1>] <f 2> [TO <g 2>] ...

FROM DATABASE <dbtab>(<ar>)

[CLIENT <cli>] ID <key>|MAJOR-ID <maid> [MINOR-ID <miid>].

This statement reads the data objects specified in the list from a cluster in the database <dbtab>. You must declare <dbtab> using a TABLES statement. If you do not use the TO <g i > option, the data object <f i > in the database is assigned to the data object in the program with the same name. If you do use the option, the data object <f i > is read from the database into the field <g i >.

Deleting Data Clusters from Cluster Databases:

DELETE FROM DATABASE <dbtab>(<ar>) [CLIENT <cli>] ID <key>.

This statement deletes the entire cluster in area <ar> with the name <key> from the database table <dbtab>. You must declare <dbtab> using a TABLES statement.

I guess this will be enough to capture the functionality for the first look.

*--Serdar