ABAP Keyword Documentation →  ABAP − Reference →  Obsolete Language Elements →  Obsolete Declarations →  Internal Tables 

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

• Properties of Header Lines

• Use

Other versions: 7.31 | 7.40 | 7.54

Declaration of Header Lines

Header lines of internal tables are created

• by using the addition WITH HEADER LINE of the statement DATA to declare internal tables,

• when using the obsolete statement string DATA - BEGIN OF OCCURS to declare structured standard tables,

• when using the obsolete statement RANGES to declare ranges tables,

• when declaring selection tables with the statement SELECT-OPTIONS,

• when using table parameters for function modules and subroutines.

Note

The statement 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 ... IN in 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

• When saving and reading data clusters using EXPORT and IMPORT.

• In the statement FREE.

• In the obsolete statement SEARCH.

• 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 table expression.

Notes

• When a LIKE reference 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 []).

Use

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 LINE and the statement string DATA - BEGIN OF OCCURS should no longer be used and ranges tables should no longer be declared using RANGES.

• 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.

Notes

• A work area for replacing a header line can be declared very simply by using the addition LINE OF of the statements TYPES, 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.

Example

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.

FUNCTION work_with_tables.
*"---------------------------------
*"*"Local Interface
*"  TABLES
*"      table STRUCTURE  structure
*"----------------------------------

  CLEAR table.

  ...

ENDFUNCTION.

Continue

DATA - HEADER LINE

DATA - BEGIN OF OCCURS

RANGES