ARTICLE
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.
After that, at least one key field of type CHAR of any name must
follow. It stores the identifier specified in id in the length of
the key field. If more than one key field is defined, the identifier is
divided among them according to the respective length of the key fields.
If the total length of the key fields is not sufficient for the
identifier, it is truncated on the right side.
The next 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 choosable names and types may
follow, which are provided with values by the specification of FROM
wa . Addition TO wa of the IMPORT statement reads these
fields out 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.
Notes
The freely definable fields between SRTF2 and CLUSTR can
be used to store status information for a stored data cluster, such as
data, user, or language.
The total length of all keys fields ( MANDT , RELID , the key
fields for the ID, and SRTF2 ) is restricted to 900 bytes (as for
each AS ABAP relational database ). If the
table content is to be transported by specifying a key, this must be
restricted to 120 bytes, whereby the SRTF2 key field does not
generally have to be specified since it only makes sense to transport
all of the rows of a data cluster.
Database table INDX delivered by
SAP has the required structure and can be used as a template for
creating your own database tables or for test purposes. In live
programs, however, we expressly recommend that you work with your own
INDX -type database tables. There are
two reasons for this. Firstly, when storing data in the INDX ,
there is a risk of unintentionally overwriting or deleting other
programs. Secondly, the freely-definable fields between SRTF2 and
CLUSTR do not normally lend themselves to this type of use.
For information on how to handle INDX -type database tables with
SQL , see SQL Access to
INDX -Type Database Tables .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved