ABAPEXPORT_DATA_CLUSTER_MEDIUM - EXPORT DATA CLUSTER MEDIUM

PERFORM Short Reference   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.

EXPORT - medium

Short Reference

Syntax

... { 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 theABAP memory, in a database table dbtab, or in a shared memory area(SHARED MEMORY or BUFFER specified) .

Alternative 1

... DATA BUFFER xstr

Effect

If DATA BUFFER is specified, the data cluster is written to the elementary data object xstr,which has to be of the type xstring. The previous content of xstr is overwritten completely.

Notes

• A data object xstr filled by EXPORT TO DATA BUFFER contains exactly one data cluster.
  
• A common application of the addition DATA BUFFER is to store the generated data cluster in afield of a database table with the corresponding data type. In this case, you should consider compressingthe data cluster using the addition COMPRESSION,since, by default, compression as a medium is only activated if DATABASE is specified directly.
  
• The content of a data object filled by EXPORT TO DATA BUFFER can only be evaluated using IMPORTFROM DATA BUFFER. In other evaluations, for example when comparing data clusters, the result is not defined. For example, the undefined content ofalignmentgaps in structures can result in different data clusters with structures that otherwise have the same content.
  
  
  

Alternative 2

... INTERNAL TABLE itab

Effect

If INTERNAL TABLE is specified, the data cluster is stored in the internal table itab. The previous content of itab is overwritten completely.

The first column of itab must have the data type sor iand the second column must have the type x. Depending on the width of the second column, thedata is stored across multiple table rows if necessary. The first row contains the length occupied in the second row. The only table type allowed for itab arestandard tables withoutsecondary table keys.

Notes

• An internal table itab filled by EXPORT TO INTERNAL TABLE contains exactly one data cluster.
  
• The content of an internal table filled by EXPORT TO INTERNAL TABLE can only be evaluated using IMPORT FROM INTERNAL TABLE for the same reasons as for EXPORT TO DATA BUFFER.
  
• The variant EXPORT TO DATA BUFFER is preferred over the variant EXPORT TO INTERNAL TABLE because it is easier to handle. An export to an internal table is of benefit only for very large data clusters and if the availablememoryis almost used up. This is because its memory is requested block by block, while the memory for a string must always be completely available.
  
  
  

Alternative 3

... MEMORY ID id

Effect

If MEMORY is specified, the data cluster is written in toABAP Memory with the ID specified in id. id expects aflatcharacter-likedata object containing a case-sensitive ID with a maximum of 60 characters. Any existing data clusterswith the same ID id are completely overwritten. The ID in id identifies a data cluster in the repository and can be read again using the same identification.

Notes

• A data cluster in the ABAP memory is available to all programs within acall sequence, whereby data can be passed to called programs.
  
• Outside of classes, an obsoleteshort form exists, in which the addition ID can be omitted. However, this is prone to errors, since all EXPORT statements without ID overwrite the same data cluster.
  
  
  

Example

Two fields with two different IDs "P1" and "P2" with the dynamic variant of the cluster definition arewritten to the ABAP memory. After the statement IMPORTis executed, the contents of the fields text1 and text2 are swapped.

TYPES:
  BEGIN OF tab_type,
    para TYPE string,
    dobj TYPE string,
  END OF tab_type.

DATA:
  id    TYPE c LENGTH 10 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

If DATABASE is specified, the data cluster with the ID id is stored in the data base table dbtab and saved permanently at the nextdatabase commit. In ABAP Dictionary, the database table must be defined with a fixedINDX-likestructure. id expects aflatcharacter-likedata object containing an ID no longer than the key fields of the INDX-like table defined between the columnsRELID andSRTF2. The ID is case-sensitive.

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

After FROM, a work area wa can be specified that must have the same data type as the database table dbtab. In an export, the current values of the components of wa, which are located between the fieldsSRTF2 andCLUSTR,are written to all rows occupied by the data cluster of the database table. If the addition FROMwa is not specified within classes, then no data transport takes place in these database fields.If the addition FROM wa is not specified outside of classes, but the statement TABLES is used to declare atablework area for the database table dbtab, then, in the export, the current values of the corresponding components of the table work area dbtab are written to the rows of the database table.

If the database table dbtab is client-specific, then a flat character-like field cl can be specified after the addition CLIENT. This field contains aclientID. If the addition is not specified, the current client is used. The column MANDT of every row in the database table occupied by the data cluster is filled by this client ID in the export.

Notes

• Data clusters in databases are not converted when migrating from a non-Unicode database to aUnicodesystem. In a Unicode system, therefore, data clusters may sometimes exist that contain non-Unicodecharacters. These characters are automatically converted to Unicode characters in each import. Whendata is exported in Unicode systems, any Unicode characters in the stored data objects are saved in accordance with the relevant platform.
  
• It is still possible to use a table work area implicitly (instead of using FROM waexplicitly). This should be considered anobsolete short form, however.
  
• Since each client represents a self-contained unit, the addition CLIENT must not be used in application programs. This is checked by the ABAP runtime environment inMultitenancy systems.
  
  
  

Example

An internal table itab is exported under the name tab and the ID "TABLE" to the area "XY" of the database tableINDX (delivered by SAP). The freely 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

If SHARED MEMORY or SHARED BUFFER is specified, the data cluster is stored incross-transaction application buffers of theshared memory on theapplication server. All programs of the same application server have access to these buffers.

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 using theprofile parameterrsdb/esm/buffersize_kb (SHARED MEMORY) andrsdb/obj/buffersize(SHARED BUFFER). Before the maximum limit of the SHARED MEMORY buffer is reached, youmust free some space using the statement DELETEFROM SHARED MEMORY, otherwise a handleable exception is raised. The buffer of SHARED BUFFERis cleared automatically by a displacement 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. The row structureof this table is defined using dbtab. For dbtab, you have to specify a database table from ABAP dictionary that has the samestructureif stored in the database table itself. The row area ar, the work area wa, the optionalclient cl, and the ID id have the same significance for the memory table as if saved ina database table, with the exception that the length of the ID in id is limited to 59 or 62 characters depending on whether the addition CLIENT is specified or not.

Notes

• When storing data in the shared memory, reference is made to a database table, even if the data is not stored in the table itself, but in an appropriately structured memory table.
  
  
• When exporting data, you overwrite any data clusters that have the same client cl, row area ar,and ID id. If an existing data cluster is to be overwritten by a bigger one when using SHARED MEMORY, and this would exceed the memory limit, then this only deletes the existing data cluster.
  
  
• Instead of saving data clusters in the shared memory, we recommend that you usesharedobjects. Shared objects allow you to store objects with complex dependencies, can be processed like normal objects, and enable several users to access the shared memory without any copying effort.
  
  
  

Fill RESBD Structure from EBP Component Structure   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.


Length: 18269 Date: 20120522 Time: 054136     triton ( 473 ms )