ABAP Keyword Documentation → ABAP − Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → READ TABLE itab

READ TABLE - table_key

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... { FROM wa [USING KEY keyname] } 

  | { WITH TABLE KEY [keyname COMPONENTS] 

              
      {comp_name1|(name1)} = operand1 

              
      {comp_name2|(name2)} = operand2 

              
      ...           
                 } ...

Alternatives

1. ... FROM wa [USING KEY keyname]

2. ... WITH TABLE KEY [keyname COMPONENTS] ...

Effect

Specifying a Table Key as a Search Key Either the primary table key or a secondary table key can be specified. The values can be declared either implicitly in a work area wa behind FROM or by listing the components of the table key explicitly behind TABLE KEY.

When the primary table key is used, the table categories are accessed as follows:

Standard tables are searched in a linear fashion.
Binary scans are used for sorted tables.
The hash algorithm is used for hashed tables.

When the secondary table key is used, a binary scan is used in the sorted key case and a hash algorithm is used in the hash key case.

When a row is found, the system field sy-tabix is set as specified by the table key in use:

For sorted keys, it is set to the number of rows found in the associated table index.
For hash keys it is set to the value 0.

If no row is found, and in the case of sorted keys, sy-tabix is set to the row number of the entry in the associated table index in front of which the row would be inserted using INSERT ... INDEX ..., to preserve the sort.

Note

Note that the system field sy-tabix is always set with reference to the table key used. If the value of the sy-tabix is used as an index after the READ statement is executed in another processing statement for the internal table, the same table key should be used there. It is important to note here that the primary index is always addressed if there is no key is specified explicitly.

Alternative 1

... FROM wa [USING KEY keyname]

Effect

For wa, a work area compatible to the row type of the internal table must be specified. This concerns functional operand positions. The first row of the internal table found, whose values in the columns of the table key used match those of the corresponding components of wa, is processed. If the key fields in wa are empty, no entries are processed.

If the USING KEY addition is not specified, the primary table key is used. If the USING KEY addition is specified, the table key specified in keyname is used.

If the primary table key is used to access a standard table and the key is empty, the first row of the internal table is read. If this is known statically, the syntax check produces a warning.

Notes

When using the primary table key, note that this key can be the standard key, which can also have unexpected consequences:

For structured row types, the standard key covers all character-like and byte-like components.

The standard key of a standard table can be empty.

Apart from classes, the FROM wa declaration can be left out if the internal table has an itab header line with the same name. The statement then does not evaluate the content of the primary table key in the header line; instead, it evaluates the content of the standard key; initial fields are subject to special handling (see READ TABLE - obsolete_key).

Example

Reads rows of the internal table spfli_tab using the primary table key. The READ statement evaluates the spfli_key work area.

DATA: spfli_tab TYPE SORTED TABLE OF spfli 
                WITH UNIQUE KEY carrid connid 
                WITH NON-UNIQUE SORTED KEY city_key 
                               COMPONENTS cityfrom cityto, 
      spfli_key LIKE LINE OF spfli_tab. 

... 

spfli_key = VALUE #( carrid = 'LH' connid = '0400' ). 
READ TABLE spfli_tab FROM spfli_key ASSIGNING FIELD-SYMBOL(<spfli>). 

IF sy-subrc = 0. 
  ... 
ENDIF.

Alternative 2

... WITH TABLE KEY [keyname COMPONENTS] ...

Effect

Each component of the table key used must be listed either directly as comp_name1 comp_name2 ... or as a parenthesized character-like data object name1 name2 ..., which contains the name of the component when the statement is executed. name is not case-sensitive. If name only contains blanks, this specified component is ignored when the statement is executed. An operand operand1 operand2 ... compatible with the data type of the component or convertible to it must be assigned to every component. The first row of the internal table found, whose values in the column of the table key used correspond with the values in the operands operand1 operand2 ... assigned, is processed. Duplicate or overlapping keys cannot be specified, nor can columns be specified that are not components of the table key.

operand1 operand2 ... are general expression positions. If necessary, the content of the operands is converted to the data type of the components before the comparison. If a conversion error occurs here, the exception cannot be handled using CX_SY_CONVERSION_ERROR and the associated runtime error occurs instead. If an arithmetic expression is specified, the calculation type is determined from its operands and the data type of the component and the result, if necessary, is converted to the data type of the component.

If the addition COMPONENTS is not specified, the primary table key is used. If the addition COMPONENTS is specified, the table key specified in keyname is used.

Notes

The pseudo component table_line can be specified as a component for tables with an unstructured row type, if their whole table entry is defined as a table key.
If WITH TABLE KEY is used, note that the values of incompatible operands operand1 operand2 ... are converted to the data type of the columns before the comparison. This means that the comparison rules do not apply to incompatible data types. If a WHERE condition is used in the statements LOOP, MODIFY, and DELETE, however, the comparison rules do apply, which can produce differing results.
To avoid unexpected results after a conversion, operand1 operand2 ... must be compatible with the data type of the component.
If the row type of the internal table is not known statically, the components of the key can only be specified dynamically and not directly.
A customizing include must not be specified as a component if it is empty.
Table expressions enable reads to be performed in operand positions too. A table key is used whenever it is specified explicitly using key.

Example

Reads rows of the internal table spfli_tab using a secondary table key. The components of the secondary table key city_key are specified explicitly in the READ statement.

DATA spfli_tab TYPE SORTED TABLE OF spfli 
               WITH UNIQUE KEY carrid connid 
               WITH NON-UNIQUE SORTED KEY city_key 
                              COMPONENTS cityfrom cityto. 

READ TABLE spfli_tab 
           WITH TABLE KEY city_key 
                COMPONENTS cityfrom = 'LH' cityto = '2402' 
           ASSIGNING FIELD-SYMBOL(<spfli>). 

IF sy-subrc = 0. 
  ... 
ENDIF.

Executable Example

Key Accesses