Internal Tables with Header Line
Outside classes, and if it is not a component of a structure or row in another internal table, it is still possible to create an internal table with a header line.
Declaration of Header Lines
Header lines of internal tables are created
- by using the addition
WITH HEADER LINEof the statement
DATAto declare internal tables,
- when using the obsolete statement string
BEGIN OF OCCURSto declare structured standard tables,
CREATE DATA cannot be used to create internal tables with header lines.
Properties of Header Lines
A header line is a work area whose
- data type is the same as the row type of the internal table
- whose name is the same as the name of the internal table.
If a header line exists, therefore, an ABAP program includes two data objects with the same name (the actual internal table and the header line). The internal table and header line are accessed as follows:
- Many processing statements for internal tables have obsolete short forms in which the header lines is used as an implicit work area if no explicit work area is specified.
- In all other cases, the statement and operand position decide whether the table body or the header line is used when the table name is specified. The header line is the usual choice. The name (and just the name) of an internal table with header line is interpreted as the table body only in the following cases:
- Operand positions in the processing statements for internal tables in which the internal table to be processed is specified.
- Operand positions in expressions in which an internal table is expected, as after
FOR ... INin a table iteration.
- Operand positions in other statements whose operand type is an internal table, such as after
SPLIT ... INTO TABLE, CONCATENATE LINES OF, SELECT ... INTO TABLE, and
READ REPORT ... INTO.
- Internal table specified in a table expression
- In the statement
- In the obsolete statement
- When a token is specified dynamically in ABAP SQL (except when database tables are specified).
To force access to the table body in any operand position when a header line exists, square brackets
can be specified directly after the name of an internal table in all operand positions (for example,
itab). This does not apply, however, when specifying the internal table in a
- When a
LIKEreference is made to an internal table with header line, either the header line itself can be referenced or
can be specified to reference the table body. It is not possible, however, to reference the internal table including the header line.
- A field symbol, a formal parameter (with the exception of table parameters), or a data reference can only address either the table body or the header line. This means that a field symbol, a formal parameter (with the exception of table parameters), or a data reference can never be ambiguous.
- Both the table body and the header line are passed when a table with header line is passed to table parameters.
can be specified for internal tables without header line, but does not need to be. This is because the name (without
) of an internal table without header line is interpreted as the table body in all operand positions regardless.
- In many operand positions that expect internal tables, the syntax check forces
to be specified after the name of an internal table with header line.
- RTTS does not support internal tables with header lines. A type description object can describe either only the header line or the table body.
- In very old programs, it may be the case that the obsolete pseudo component
*sys*is used to address the header line (instead of
The use of header lines is highly error-prone, due to the repeated use of one name for two data objects. If at all possible, avoid creating and using header lines (even outside of classes).
- The addition
WITH HEADER LINEand the statement string
BEGIN OF OCCURSshould no longer be used and ranges tables should no longer be declared using
- Avoid using table parameters if at all possible.
- In cases where a header line absolutely has to be created (such as in selection tables or in procedures that still require table parameters (generally only remote-enabled function modules)), never work with the header line and use the additional explicitly work areas declared explicitly instead.
- A work area for replacing a header line can be declared very simply by using the addition
LINE OF of the statements
DATA, and so on.
- The use of an additional work area should not be confused with the explicit completion of the implicit
short forms, such as
LOOP AT itab INTO itab. The latter case is one of the undesired ways to use a header line.
- Tables with header lines do not offer any performance advantages.
The following example shows a typical instance of handling internal tables with header lines: An internal
table with header line (here the table parameter of a function module) is initialized using
CLEAR, but the
 is not appended to the name. In this case, only the header line is deleted, which is not usually noticed until runtime.
*" table STRUCTURE structure