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

READ TABLE - table_key

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax

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

  | { WITH TABLE KEY [keyname COMPONENTS] 

                     {comp_name1|(name1)} = dobj1 

                     {comp_name2|(name2)} = dobj2 

              
      ...                           } ... . 

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.

Note

Note that the sy-tabix system field is always set in relation to the used table key. If the value of sy-tabix is used as an index specification following the execution of the READ statement in another processing statement for the internal table, the same table key should be used there, whereby it is important to note that the primary index is always addressed if there is no explicit key specification.

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, then the first row of the internal table is read.

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

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 blank spaces, this component specification is ignored in the execution of the statement. A data object dobj1 dobj2 ..., which is compatible with the data type of the component or that can be converted 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 data object dobj1 dobj2 ... assigned, is processed. If necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison. No duplicate or overlapping key declarations can be made.

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 data objects dobj1 dobj2 ... 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, dobj1 dobj2 ... must be compatible with the data type of the component.
• A Customizing include must not be specified as a component if it is empty.
  

Example

For different key inputs, see Key Access.

Example

Reads rows of the internal table spfli_tab using the primary table key and a secondary table key. The first READ statement evaluates the work area spfli_key; the second READ statement specifies the components of the secondary table key city_key explicitly.

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. 

FIELD-SYMBOLS <spfli> TYPE spfli. 

... 

spfli_key-carrid = 'LH'. 
spfli_key-connid = '0400'. 
READ TABLE spfli_tab FROM spfli_key ASSIGNING <spfli>. 

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

... 

READ TABLE spfli_tab 
           WITH TABLE KEY city_key 
                COMPONENTS cityfrom = 'LH' cityto = '2402' 
           ASSIGNING <spfli>. 

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