Get Example source ABAP code based on a different SAP table
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.