Secondary Table Key
Access to an internal table using a secondary key is always optimized. This allows additional optimized keys to be introduced for sorted and hashed tables as well as optimized key accesses for standard tables.
- Declaration of secondary table keys
UNIQUE|NON-UNIQUE KEY key_name COMPONENTSof statements
DATAand so on. For table types created in ABAP Dictionary, the tool provides the corresponding functions.
- Access using secondary keys
WITH [TABLE] KEY key_namecan be used in processing statements to specify which secondary table key to use. In index accesses,
USING KEY keynamecan be used to specify the table index of which secondary key to use. In table expressions, this is specified using the addition
KEY. Secondary keys are not selected automatically. If no secondary key is specified in a processing statement, the primary key or primary table index is always used. If no explicit key is specified for a table expression, a free search key is used to perform reads.
READ TABLE itab
The rows to be read can be specified using a secondary key.
LOOP AT itab
The processing order and conditions can be controlled using a secondary table key.
Only a secondary key for the source table can be specified here, from which multiple rows are copied. The position they are inserted at is determined solely using the primary key and the primary index.
Only a secondary key for the source table can be specified here, onto which multiple rows are appended.
The rows to be modified can be specified using a secondary key.
The rows to be deleted can be specified using a secondary key.
TYPES ... ASSOCIATION, \_assoc[ ... ]
The secondary key used in the evaluation of a mesh path can be specified using
sy-tabixis set by this type of access, and a sorted secondary key is used, the row number refers to the associated secondary table index. In statements that these additions has not been introduced for, like SORT,
PROVIDE, secondary keys are not explicitly supported.
The key fields of a secondary table key are only write-protected if the secondary table key is in use
LOOP loop or in a
MODIFY statement. Otherwise, the secondary key fields are not write-protected.
- Optimized access times for the individual rows using secondary keys are bought in exchange for the fact that the ABAP runtime environment then needs to administer the additional keys. For hash keys, this means additional hash administration. For each sorted key, it means an additional secondary table index.
- When working with internal tables for which a secondary key is declared, it must be ensured that the required key or table index is used in the processing statements.
Declaration of a hashed table with a unique primary key and a non-unique sorted secondary key
cities. The table is filled with data from a database table, read using a
table expression with values specified for the secondary key. The first row found is read.
DATA cityfrom TYPE spfli-cityfrom VALUE 'FRANKFURT'. cl_demo_input=>add_field( CHANGING field = cityfrom ). DATA cityto TYPE spfli-cityto VALUE 'NEW YORK'. cl_demo_input=>request( CHANGING field = cityto ). DATA spfli_tab TYPE HASHED TABLE OF spfli WITH UNIQUE KEY primary_key COMPONENTS carrid connid WITH NON-UNIQUE SORTED KEY cities COMPONENTS cityfrom cityto. SELECT * FROM spfli INTO TABLE @spfli_tab. cl_demo_output=>display( VALUE #( spfli_tab[ KEY cities cityfrom = cityfrom cityto = cityto ] OPTIONAL ) ).