Get Example source ABAP code based on a different SAP table
ABAP_ITAB - Secondary Table Key Hash keys> and sorted keys> can be declared as secondary table keys> for each internal table. For each sorted key, an additional secondary table index> is created. 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 For data types declared in ABAP programs, a secondary table is declared using the additions UNIQUE$|NON-UNIQUE KEY key_name COMPONENTS>> of the statements TYPES>>, DATA>>, and so on. The ABAP Dictionary provides corresponding functions for the table types created in the tool.
Access Using Secondary Keys In key accesses to internal tables, the addition WITH $[TABLE$] KEY key_name> can be used in processing statements> to specify which secondary table key to use. In index accesses, the specification USING KEY keyname> can 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. Statements where secondary keys can be specified are:
READ TABLE itab>>
The lines to be read can be specified using a secondary key.
LOOP AT itab>>
The processing sequence and conditions can be controlled using a secondary table key.
INSERT itab>>
Only a secondary key for the source table can be specified here, from which multiple lines are copied. The insertion position is determined solely using the primary key and the primary index.
APPEND>>
Only a secondary key for the source table can be specified here, onto which multiple lines are appended.
MODIFY itab>>
The lines to be modified can be specified using a secondary key.
DELETE itab>>
The lines 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 USING KEY>. If the system field sy-tabix> is set in this type of access, and a sorted secondary key is used, the line number refers to the associated secondary table index>. In statements that have not been enhanced by these additions, like SORT>>, COLLECT>>, or 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 within a LOOP> or a MODIFY > statement. Otherwise, the secondary key fields are not write-protected.
ABAP_PGL Secondary Key> ABAP_PGL_END
Latest notes:
Optimized access times to the individual lines using secondary keys are bought> in exchange for the fact that the ABAP runtime framework then needs to administer the additional keys. For hash keys, this means additional hash administration and an additional secondary table index > for each sorted key.
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. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 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 and accessed using a table expression> with values specified for the secondary key. The first line found is read. ABEXA 01061 ABAP_EXAMPLE_END