EXPORT - medium
Short Reference
ABAP 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 } ... .
ABAP_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
What does it do? The exported data cluster
can be stored in a byte string xstr , in an internal table
itab , in the ABAP memory , in a
database table dbtab , or in a shared memory area ( SHARED
MEMORY or BUFFER specified) .
ABAP_ALTERNATIVE_1 ... DATA BUFFER xstr
What does it do? 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.
Latest 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 a field of a database table with the
corresponding data type. In this case, consider compressing the 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 IMPORT FROM DATA BUFFER . In other
evaluations, for example when comparing data clusters, the result is not
defined. For example, the undefined content of
alignment gaps in structures can result
in different data clusters with structures that otherwise have the same
content.
ABAP_ALTERNATIVE_2 ... INTERNAL TABLE itab
What does it do? 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
s or
i and the second column must
have the type x . Depending on the width of the second column, the
data 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 are standard
tables without secondary table
keys .
Latest 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 available memory is
almost used up. This is because its memory is requested block by block,
while the memory for a string must always be completely available.
ABAP_ALTERNATIVE_3 ... MEMORY ID id
What does it do? If MEMORY is specified, the data cluster is
written in to ABAP Memory with the ID
specified in id . id expects a flat
character-like data object
containing a case-sensitive ID with a maximum of 60 characters. Any
existing data clusters with 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.
Latest notes: A data cluster in the ABAP memory is available to all
programs within a call sequence ,
whereby data can be passed to called programs.
Outside of classes, an obsolete
short 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 ABAP Coding Two fields with two different IDs "P1" and
"P2" with the dynamic variant of the cluster definition are written
to the ABAP memory . After the statement
IMPORT is 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.
ABAP_ALTERNATIVE_4 ... DATABASE dbtab(ar) [FROM wa] [CLIENT cl]
ID id
What does it do? If DATABASE is specified, the data cluster with
the ID id is stored in the data base table dbtab and saved
permanently at the next database commit
. In ABAP Dictionary, the database table must be defined with a fixed
INDX -like
structure . id expects a
flat
character-like data object containing an ID no longer than the key
fields of the INDX -like table defined between the columns
RELID and
SRTF2 . The ID is
case-sensitive.
The two-character 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 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 fields SRTF2
and CLUSTR , are
written to all rows occupied by the data cluster of the database table.
If the addition FROM wa 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 a
table work 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 a
client ID . 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.
Latest notes: Data clusters in databases are not converted when
migrating from a non-Unicode database to a
Unicode system . In a Unicode system,
therefore, data clusters may sometimes exist that contain non-Unicode
characters. These characters are automatically converted to Unicode
characters in each import. When data 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 wa explicitly). This should be considered an
obsolete 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 in
multitenancy systems.
Example ABAP Coding An internal table itab with the name tab
and the ID "TABLE" is exported to the area "SQ"
of the database table DEMO_INDX_TABLE
, filling the freely selectable components from the structure
wa_indx .
TYPES:
BEGIN OF tab_type,
col1 TYPE i,
col2 TYPE i,
END OF tab_type.
DATA:
wa_indx TYPE demo_indx_table,
wa_itab TYPE tab_type,
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-timestamp = sy-datum <(> <)><(> <)> sy-uzeit.
wa_indx-userid = sy-uname.
EXPORT tab = itab
TO DATABASE demo_indx_table(SQ)
FROM wa_indx
ID 'TABLE'.
ABAP_ALTERNATIVE_5 ... SHARED MEMORY dbtab(ar) [FROM wa] [CLIENT
cl] ID id
ABAP_ALTERNATIVE_6 ... SHARED BUFFER dbtab(ar) [FROM wa] [CLIENT
cl] ID id
What does it do? If SHARED MEMORY or SHARED BUFFER is
specified, the data cluster is stored in
cross-transaction application
buffers of the shared memory on the
application 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 the
profile parameter
rsdb/esm/buffersize_kb ( SHARED
MEMORY ) and rsdb/obj/buffersize
( SHARED BUFFER ). Before the maximum limit of the SHARED
MEMORY buffer is reached, space must be freed using the statement
DELETE FROM SHARED MEMORY ; otherwise a
handleable exception is raised. The buffer of SHARED BUFFER is
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 structure of this table is defined using
dbtab . For dbtab , a database table from ABAP Dictionary
must be specified that has the same
structure if stored in the database table itself. The row area ar
, the work area wa , the optional client cl , and the ID
id have the same significance for the memory table as if saved in
a 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.
Latest 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.
The length of the key fields of the INDX -like table addressed
between the columns RELID
and SRTF2 cannot exceed 59
or 62 characters, depending on whether a client column exists.
When data is exported, any data clusters that have the same client
cl , row area ar , and ID id are overwritten. 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 shared objects are used. Shared
objects allow objects to be stored with complex dependencies, to be
processed like normal objects, and enable multiple users to access the
shared memory without any copying effort.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved