ABAP Keyword Documentation → ABAP - Reference → Obsolete Language Elements → Obsolete modularization → Function Modules → FUNCTION - table_parameters
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 afterwa
.
- The following statements terminated when
wa
is shorter than the row type:
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.