DATA - TABLE OF

Syntax

DATA itab { {TYPE tabkind OF [REF TO] type}
          | {LIKE tabkind OF dobj} }
          [WITH key] [INITIAL SIZE n]
          [WITH HEADER LINE]
          [VALUE IS INITIAL]
          [READ-ONLY].

Addition:

... WITH HEADER LINE

Effect

This statement defines an internal table. The definition of the row type, table kind tabkind and initial memory size INITIAL SIZE exactly corresponds to the definition of table types in section TYPES - TABLE OF, except that you cannot use the generic types ANY TABLE and INDEX TABLE. Use DATA to generate a bound table type with these additions.

The syntax for defining the table key key is also the same as for defining table types. In contrast to the definition of table types, an internal table as a data object cannot have a generic table key. This results in a slightly different semantics when you omit the table key specification in the DATA statement or when you do not specify the uniqueness using UNIQUE or NON-UNIQUE:

• If for standard tables you specify no key, the table key is automatically determined as a non-unique standard key. A key specified without explicit uniqueness is implicitly enhanced with the addition NON-UNIQUE KEY. You cannot specify addition UNIQUE KEY.
  
  
• For sorted tables, you must specify the key fully; both additions UNIQUE KEY or NON-UNIQUE KEY are allowed.
  
  
• For hashed tables, you must specify the key fully; only addition UNIQUE KEY is allowed.
  
  
  

When defining internal tables before release 6.40, you could not specify a start value with addition VALUE. As of release 6.40, you can specify IS INITIAL as a start value.

Notes

• When creating an internal table as a data object, only the administration entry for an internal table is generated. The actual table rows are not inserted until runtime. Under Obsolete Declarations, obsolete declaration forms for standard tables and special tables are described.
  
  
  

Example

Declaration of an internal table. The row type corresponds to the structure of database table SPFLI. For the table key, two key fields are defined. The other statements show how to fill the table with rows from database table SPFLI and how to read a row.

DATA: spfli_tab TYPE HASHED TABLE OF spfli
                WITH UNIQUE KEY carrid connid,
      spfli_wa  LIKE LINE OF spfli_tab.

SELECT *
       FROM spfli
       INTO TABLE spfli_tab
       WHERE  carrid = 'LH'.

READ TABLE spfli_tab
           WITH TABLE KEY carrid =  'LH' connid =  '0400'
           INTO spfli_wa.

           ...

Addition

... WITH HEADER LINE

Effect

Apart from the internal table, this addition, which is not allowed in classes, declares another data object, the header line, which has exactly the same name as the internal table and has the row type of the internal table as the data type.

If at an operand position of an ABAP statement, you specify the name of internal table itab, it depends on the statement whether the table body or the header line are used. As a rule, all table-specific statements such as SORT or LOOP use the internal table, while all other statements use the header line. Exceptions are - among others - the statements IMPORT andEXPORT.

To address the table body instead of the header line in a statement, you can append [] to the name (or a field symbol or dereferenced data reference):

... itab[] ...

For internal tables without header line, the table body is always used. An internal table with a header line can not be a component of a structure or a row of another internal table.

Note

These statements for processing individual table rows have short forms that implicitly use the header line as work area. These short forms are allowed only outside of ABAP Objects.