Kontakt

Ansicht
Dokumentation

ABAPREAD_TABLE_KEY - READ TABLE KEY

ABAPREAD_TABLE_KEY - READ TABLE KEY

BAL_S_LOG - Application Log: Log header data   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

READ TABLE, table_key

Short Reference



... ${ 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

Enter table key as a search key. The values of the search key 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:

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 line is found, the system field sy-tabix is set as specified by the table key used:

  • For sorted keys to the number of lines found in the associated table index.
  • For hash keys to the value 0.

If no line is found, sy-tabix is set to the line number of the entry in the associated table index in the case of a sorted key, in front of which the line searched for would be inserted using INSERT ... INDEX ..., to preserve the sort.

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, the first line of the internal table is read. If this is known statically, the syntax check produces a warning.

Notes

  • When using the primary table key, it should be noted that this key can also be the standard key, which can have unexpected consequences:
  • For structured line types, the standard key covers all character-like and byte-like components.

  • The standard key of a standard table can be empty.

  • Outside of classes, the specification FROM wa can be omitted if the internal table has an identically named itab header line. The statement then does not evaluate the content of the primary table key in the header line, and it evaluates the content of the standard key instead. Initial fields are handled in a special way (see READ TABLE - obsolete_key).

Example

Reading of lines of the internal table spfli_tab using the primary table key and a secondary key city_key. The READ statement evaluates the spfli_key work area.

Alternative 2

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


Effect

Every component of the table key used must be executed, either directly as comp_name1 comp_name2 ..., or as a bracketed character-type data object name1 name2 ..., which contains the name of the component during the execution of the statement. comp_name1 comp_name2 ... are functional operand positions. 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 ..., that 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 it is necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison.

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.

  • To avoid unexpected results after a conversion, dobj1 dobj2 ... must be compatible with the data type of the component.

No Customizing include may be specified as a component if it is empty.

  • Table expressions allow corresponding reads to also be performed in operand positions. A table key is used if it is specified explicitly using key.

Example

Reading of lines of the internal table spfli_tab using the primary key and a secondary table key city_key. The components of the table keys are specified explicitly in the READ statement.

Key Accesses








Vendor Master (General Section)   CPI1466 during Backup  
This documentation is copyright by SAP AG.

Length: 10327 Date: 20240419 Time: 181954     sap01-206 ( 144 ms )