EXPORT obj1 ... objn TO SHARED MEMORY

[Former Member]

Hi....

Can any one give me the exact syntax for the same.....Please with the example....

Regards

Suresh Kumar

[sreeramkumar_madisetty]

Hi

Find the syntaxes:

EXPORT obj1 ... objn TO DATA BUFFER f.

- EXPORT obj1 ... objn TO MEMORY.

- EXPORT obj1 ... objn TO SHARED MEMORY itab(ar) ID key.

- EXPORT obj1 ... objn TO SHARED BUFFER itab(ar) ID key.

- EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.

- EXPORT obj1 ... objn TO DATASET dsn(ar) ID key.

- EXPORT (itab) TO ... .

Regards,

kumar

[Former Member]

EXPORT parameter_list TO medium [COMPRESSION {ON|OFF}].

Addition:

... COMPRESSION {ON|OFF}

Effect

This statement stores a data cluster defined using parameter_list in a storage area medium. You can use the COMPRESSION addition to specify whether the data is stored in the cluster in compressed form. You can retrieve a data cluster from the storage area using the IMPORT statement and delete a data cluster using DELETE FROM.

All data objects are archived according to the current byte sequence (endian) and character-like data objects according to the current character representation of the current text environment. The identification of the data cluster indicates which byte sequence and character representation have been used during the export. When you import the data cluster using the IMPORT statement, this identification is evaluated and the data is converted to the current byte sequence and character representation.

Note

See also Classes for Data Cluster.

Addition

... COMPRESSION {ON|OFF}

Effect

This addition specifies whether or not the data in the data cluster are compressed. By default and if you specify ON, the compression for the storage in a database is switched on. It is switched off if you specify OFF.

... {p1 = dobj1 p2 = dobj2 ...}

| {p1 FROM dobj1 p2 FROM dobj2 ...}

| (ptab) ... .

Extras:

1. ... p1 = dobj1 p2 = dobj2 ...

2. ... p1 FROM dobj1 p2 FROM dobj2 ...

3. ... (ptab)

Effect

A data cluster can be defined statically by a list p1 = dobj1 p2 = dobj2 ... or p1 FROM dobj1 p2 FROM dobj2 ... and dynamically through specification of a bracketed internal table ptab. If the data cluster is too big for the memory, an exception will be raised.

Note

To export objects, which are referenced by reference variables, use the statement CALL_TRANSFORMATION to serialize and export these objectsif the class of these objects implements the interface IF_SERIALIZABLE_OBJECT.

Addition 1

... p1 = dobj1 p2 = dobj2 ...

Addition 2

... p1 FROM dobj1 p2 FROM dobj2 ...

Effect

In case of a static export, the content of the data object dobj is stored under the name p in the cluster. The name of a parameter p can contain 255 characters at maximum. The spellings p1 = dobj1 p2 = dobj2 ... and p1 FROM dobj1 p2 FROM dobj2 ... are synonymous. You can use all data types except reference types for the data object dobj . If a data object dobj is an internal table with a header line, then not the header line is adressed, but the table body.

Outside classes you can use the short form dobj1 dobj2 ... for the static variant. In doing so, all data objects are implicitly stored under their name in the data cluster.

Addition 3

... (ptab)

Effect

In the dynamic case the parameter list is specified in an index table ptab with two columns. These columns can have any name and have to be of the type "character". In the first column of ptab, you have to specify the names of the parameters and in the second column the data objects. If the second column is initial, then the name of the parameter in the first column has to match the name of a data object. The data object is then stored under its name in the cluster. If the first column of ptab is initial, an uncatchable exception will be raised.

Outside of classes you can also use a single-column internal table for parameter_list for the dynamic form. In doing so, all data objects are implicitly stored under their name in the data cluster.

... { DATA BUFFER xstr }

| { INTERNAL TABLE itab }

| { MEMORY ID id }

| { DATABASE dbtab(ar) [FROM wa] [CLIENT cl] ID id }

| { SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id }

| { SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT cl] ID id } ... .

Alternatives:

1. ... DATA BUFFER xstr

2. ... INTERNAL TABLE itab

3. ... MEMORY ID id

4. ... DATABASE dbtab(ar) [FROM wa] [CLIENT cl] ID id

5. ... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id

6. ... SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT cl] ID id

Effect

The exported data cluster can be stored in a byte string xstr, in an internal table itab, in the ABAP memory, in a data base table dbtab or in a shared memory area (Specification SHARED MEMORY or BUFFER) .

Alternative 1

... DATA BUFFER xstr

Effect

When specifying DATA BUFFER, the data cluster is written in the elementary data object xstr, which has to be of the type xstring.

Alternative 2

... INTERNAL TABLE itab

Effect

When specifying INTERNAL TABLE, the data cluster is stored in the internal table itab. The first column of itab has to be of the data type s, the second column of the type x. Depending on the width of the second column, the data is stored in multiple table rows if neccessary. The first row contains the length occupied in the second row. As table type, you can only use standard tables for itab.

Alternative 3

... MEMORY ID id

Effect

When you specify MEMORY, the data cluster is written to the ABAP Memory with the stated ID id. id is expected to be a flat character-type data object which contains an identification not longer than 55 characters. An already existing data cluster with the same identification id is completely overwritten. By the identification in id, a data cluster is identified in the memory and can be read again with the same identification.

Obsolete short form

The addition ID can be omitted outside classes. However, this is prone to errors, as all EXPORT statements without identification overwrite the same data cluster.

Note

A data cluster in the ABAP memory is available to all programs within a call sequence, whereby data can be handed over to called programs.

Example

Two fields with two different identifications "P1" and "P2" with the dynamic variant of the cluster definition are written to the ABAP Memory. After execution of the statement IMPORT, the contents of the fields text1 and text2 are interchanged.

TYPES:

BEGIN OF tab_type,

para TYPE string,

dobj TYPE string,

END OF tab_type.

DATA:

id(10) TYPE c VALUE 'TEXTS',

text1 TYPE string VALUE `IKE`,

text2 TYPE string VALUE `TINA`,

line TYPE tab_type,

itab TYPE STANDARD TABLE OF tab_type.

line-para = 'P1'.

line-dobj = 'TEXT1'.

APPEND line TO itab.

line-para = 'P2'.

line-dobj = 'TEXT2'.

APPEND line TO itab.

EXPORT (itab) TO MEMORY ID id.

IMPORT p1 = text2

p2 = text1 FROM MEMORY ID id.

Alternative 4

... DATABASE dbtab(ar) [FROM wa] [CLIENT cl] ID id

Effect

When specifying DATABASE, the data cluster with the identification id is stored in the data base table dbtab and stored permanently at the next database-commit. For id, a flat character-type data object is expected that contains an identification of 105 or 108 characters at maximum, depending on whether the addition CLIENT is stated or not. The data base table has to be defined in the ABAP Dictionary with a fixated predetermined structure.

The double-digit area ar, which must be specified directly, splits up the rows of the database table into several areas, so that data clusters with the same identification id can exist multiple times in the data base table.

After FROM, a work area wa can be specified, which has to have the same data type as the data base table dbtab. When exporting, the current values of the components of wa , which are situated between the fields SRTF2 and CLUSTR, are written in all the rows occupied by the data cluster of the data base table.

If the data base table dbtab is client-specific, you can specify a flat character-type field cl after the additionCLIENT, which contains a client identifier. If you do not specify the addition, the current client is used. The row MANDT of every row occupied by the data cluster of the data base is filled with this client identification at export.

Obsolete short form

If outside classes, the addition FROM wa is not specified and instead a Table work area is declared for the data base table dbtab with the statement TABLES, then, at export, the current values of the components of the table work area dbtab, which are situated between the fields SRTF2 and CLUSTR are written in the rows of the data base table.

Example

An internal table itab is exported under the name tab and the identification "TABLE" to the area"XY" of the data base table INDX (delivered by SAP). The selectable components are provided by the structure wa_indx.

TYPES:

BEGIN OF tab_type,

col1 TYPE i,

col2 TYPE i,

END OF tab_type.

DATA:

wa_indx TYPE indx,

wa_itab TYPE tab_type,

cl TYPE mandt VALUE '100',

itab TYPE STANDARD TABLE OF tab_type.

WHILE sy-index < 100.

wa_itab-col1 = sy-index.

wa_itab-col2 = sy-index ** 2.

APPEND wa_itab TO itab.

ENDWHILE.

wa_indx-aedat = sy-datum.

wa_indx-usera = sy-uname.

wa_indx-pgmid = sy-repid.

EXPORT tab = itab

TO DATABASE indx(XY)

FROM wa_indx

CLIENT cl

ID 'TABLE'.

Alternative 5

... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT cl] ID id

Alternative 6

... SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT cl] ID id

Effect

When specifying SHARED MEMORY or SHARED BUFFER , the data cluster is stored in application buffers of the shared memory on the application server, on which all programs of the same application server take access together.

The two application buffers differ in respect to how the system behaves when reaching the memory limit. Both application buffers can be filled to an internal maximum limit, which can be adjusted via Profile parameter rsdb/esm/buffersize_kb (SHARED MEMORY ) and rsdb/obj/buffersize (SHARED BUFFER). Before the maximum limit of the buffer of SHARED MEMORY is reached, you have to free some space with the statment DELETE FROM SHARED MEMORY. The buffer of SHARED BUFFER is automatically cleared by a displacement procedure when it reaches the maximum limit. This procedure deletes the least used data objects from the buffer.

When storing the data, the system creates a memory table in the application buffer, whose line structure is defined with dbtab. For dbtab, you have to specify a data base table from the ABAP dictionary that has the same structure as structure if stored in the data base table. The line area ar, the work area wa, the optional client cl and the identification wa have the same significance for the memory table, as if stored in a data base table with the exception that the length of the identification is limited to id 59 resp. 62 characters depending on whether the addition CLIENT is specified or not.

Notes

When storing something in the shared memory, you refer to a data base table, even if the data is not stored in the table itself, but in an accordingly created memory table.

When exporting data, you overwrite a possibly existing data cluster with the same client cl, line area ar and identification id. If an existing data cluster is to be overwritten by a bigger one with SHARED MEMORY, which would exceed the memory limit, this only leads to the deletion of the present data cluster.

EXPORT - Table Structure

When storing data clusters in database tables and application buffers of the shared memories, you must specify database tables of the following structure:

The first field must be a key field named MANDT of type CLNT for the client, if you want to store the data objects client-specifically. For a cross-client storage, this component does not apply.

The second field must be a key field named RELID of type CHAR and length 2. It stores the area ar specification.

The third field must be a key field of type CHAR named SRTFD with a maximum length of 55 characters. It stores the identifier specified in id.

The fourth field must be a key field named SRTF2 of type INT4. It contains the row numbers of a stored data cluster that can extend over several rows and is filled automatically by the system.

Then any number of components with freely selectable names and types may follow. They are provided with values by the specification of FROM wa. Addition TO wa of the IMPORT statement exports these fields again.

The last two components must be named CLUSTR and CLUSTD and be of types INT2 and LRAW of any length. In CLUSTR, the current length of field CLUSTD of each row is stored, while CLUSTD contains the actual data cluster.

Note

The database table INDX delivered by SAP has the required structure and can be used as a pattern for creating own database tables and for testing purposes. We expressly recommend using your own INDX-type database tables in production systems.

Internal Additions

These additions are intended for internal use only.

They cannot be used in application programs.

Extras:

1. ... CODE PAGE HINT cp

2. ... USING subr

Addition 1

... CODE PAGE HINT cp

Effect

In cp, you can specify a codepage from database table TCP00, which overwrites the automatically stored ID.

Addition 2

... USING subr

Effect

This addition can be specified for EXPORT TO DATABASE if a table work area dbtab is declared for the relevant database table using TABLES. The FROM wa addition is not allowed. The data is not exported to the database table. Instead, the subroutine subr is called for each line that would be written to the database without this addition. In the subroutine, you can access the data in the table work area dbtab that would otherwise be written to the database table.

The subroutine must be defined in the same program and its name must contain the name of the database table as a prefix "dbtab_". The subroutine must have a USING parameter of the type any, which is currently not supplied.

Example

[Former Member]

Hi,

differnet syntax.

1. EXPORT obj1 ... objn TO DATA BUFFER f.

2. EXPORT obj1 ... objn TO INTERNAL TABLE itab.

2. EXPORT obj1 ... objn TO MEMORY.

3. EXPORT obj1 ... objn TO SHARED MEMORY itab(ar) ID key.

4. EXPORT obj1 ... objn TO SHARED BUFFER itab(ar) ID key.

5. EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.

6. EXPORT obj1 ... objn TO DATASET dsn(ar) ID key.

7. EXPORT (itab) TO ... .

Exports two fields and an internal table to a data buffer:

This Stores a data cluster in the data buffer f, where f has the type XSTRING. The objects declared, obj1 ... objn, are stored as a cluster in the data buffer f. They can be fields, structures, complex structures, or tables.

You must enter an explicit name for the exported data objects in classes - that is, either addition 1 or addition 2 is mandatory.

You cannot export the header lines of internal tables because specifying the name of an internal table with a header line always exports the actual table data.

You cannot export data references, object references, or interface references.

You can change the necessary length of the data buffer f at any time.

Example.

TYPES: BEGIN OF ITAB3_TYPE,

CONT(4),

END OF ITAB3_TYPE.

DATA: XSTR TYPE XSTRING,

F1 TYPE C LENGTH 4,

F2 TYPE P,

ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH

NON-UNIQUE DEFAULT KEY INITIAL SIZE 2.

EXPORT F1 FROM F1

F2 FROM F2

ITAB3 FROM ITAB3

TO DATA BUFFER XSTR.

example 2.

Export two fields and an internal table to the buffer with the structure INDX:

TYPES: BEGIN OF ITAB3_TYPE,

CONT(4),

END OF ITAB3_TYPE.

DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',

F1(4), F2 TYPE P,

ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH

NON-UNIQUE DEFAULT KEY INITIAL SIZE 2,

WA_INDX TYPE INDX.

• Before export, fill the data fields

• before CLUSTR.

WA_INDX-AEDAT = SY-DATUM.

WA_INDX-USERA = SY-UNAME.

• Export der Daten.

EXPORT F1 FROM F1

F2 FROM F2

ITAB3 FROM ITAB3

TO SHARED BUFFER INDX(ST) FROM WA_INDX ID INDXKEY.

Regards,

Sruthi

[Former Member]

Hi,

So If I use

EXPORT F1 FROM F1

F2 FROM F2

ITAB3 FROM ITAB3

TO SHARED BUFFER INDX(ST) FROM WA_INDX ID INDXKEY.

as mentionned in the previous answer, how do I can free memory after Import ?

I've tried two solutions and none is wroking :

FREE MEMORY ID INDXKEY (sy-subrc = 4)

FREE MEMORY (sy-subrc = 0) but SHARED MEMORY not free....

Thanks for helping me.

Marie