ARTICLE
Exceptions when Accessing TABLES Parameters
In some variants of statements, which use a work area to access internal
tables, the work area must be compatible with the row type of the
internal table. This is checked statically by the syntax check.
In the case of TABLES parameters typed using the obsolete
addition STRUCTURE , the
compatibility of the work area with the type specified in
STRUCTURE
is checked. The header line that
always accompanies TABLES parameters also has this type.
If a TABLES parameter is typed using STRUCTURE it can also
be bound to actual parameters whose row type is longer than the type of
the TABLES parameter, so making them incompatible with a work
area judged to be correct by the syntax check. This causes problems if
the components of the TABLES parameter are accessed dynamically
within the procedure, since the data type of the actual parameter is
evaluated at runtime. Consequently, memory limits can be violated by
statements accessing a work area that references the type specified
using STRUCTURE . This is why the following accesses produce the
runtime error ITAB_STRUC_ACCESS_VIOLATION :
The following statements terminate when the component specified in
name is used to access a memory area after wa .
READ TABLE itab
INTO wa ...
COMPARING|TRANSPORTING ... (name) ...
MODIFY itab FROM
wa TRANSPORTING ... (name) ...
APPEND wa TO itab SORTED BY ... (name) ...
The following statements terminated when wa is shorter than the
row type:
READ TABLE itab
INTO wa ... COMPARING ALL
FIELDS.
COLLECT wa INTO itab ...
This exception is particurlarly likely if the
header line is used as an implicit work
area. An explicit work area with the type of the actual parameter should
be used to avoid this runtime error.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved