What does it do? Definition of a secondary table key with an internal table type. An internal table can have up to 15 secondary keys. Types of Secondary Keys There are three types of secondary keys that are distinguished by the type of access and their uniqueness:
Unique secondary hash keys defined using UNIQUE HASHED that are linked to table lines using a hash algorithm.
Unique secondary sorted keys defined using UNIQUE SORTED that are linked to table lines using a secondary table index in which the key fields are sorted in ascending order.
Non-unique secondary sorted keys defined using NON-UNIQUE SORTED that are linked to table lines using a secondary table index in which the key fields are sorted in ascending order. Names of Secondary Keys Each secondary key has a unique name with which it can be addressed. The name must be specified directly as key_name and must comply with the naming conventions. The name specified cannot be one of the predefined names primary_key or loop_key. In addition, the names of secondary keys and any alias name for the primary key must be unique. Key Fields The key fields of the secondary key can be defined in the following ways, whereby the order is significant:
Individual components comp1 comp2 ... of the line type are listed after KEY. The line type must be structured, and the components cannot be table types nor can they contain table types as components.
If the whole table line is to be defined as a key, the pseudo component table_line can be specified as the only component comp after KEY. This is possible for all line types that are not table types or that do not contain table types as components. In an operation that changes the content of individual lines of an internal table, the key fields of a secondary table key are read-only only if the secondary key is used during this operation.
ABAP_PGL Use secondary keys in a way that benefits the table. ABAP_PGL_END
Latest notes:
When internal tables are accessed using the statements READ TABLE itab, LOOP AT itab, MODIFY itab, and DELETE itab or in reads using table expressions and in mesh types and mesh paths , a secondary key can be used to determine the lines to be processed or the processing order. To do this, the additions WITH $[TABLE$] KEY ... COMPONENTS or USING KEY must be specified. A secondary key is never used implicitly.
The statement INSERT itab determines the insert position exclusively using the primary key and primary index only. A secondary key can only be specified for the source table from which multiple lines are copied. The latter also applies to the statement APPEND.
A secondary key is never generic. When it is defined, all key fields and the uniqueness must be specified completely. An internal table type can, however, be generic with respect to its number of secondary keys.
DEFAULT KEY cannot be specified for secondary keys.
Structured components can be specified as key fields, provided that the components meet the other requirements. When a structured key field is evaluated, the rules for structure comparisons apply.
If different table keys for an internal table contain the same components, a syntax check warning occurs, which can be hidden using a pragma.
Apart from the restrictions described above, the names of secondary keys can be freely selected, but they should not use the component names of the internal table. The name loop_key is reserved for the explicitly specifying the key used for LOOP processing.
Key fields can also have reference types . However, particularly for sorted keys this is not recommended, as sorting reference variables is questionable. For non-initial invalid references, no order is defined. A runtime error occurs if such a reference must be compared in the context of a key access.
The internal management of secondary keys in an internal table can involve significant memory consumption and updates. For this reason, secondary keys should be used sparingly and only be implemented if their benefits outweigh the costs. NON_V5_HINTS
See, for example, the executable example Deleting Lines Using Keys. ABAP_HINT_END
ABAP_EXAMPLE_VX5 Definition of a table type with a primary key and two secondary keys hash_key and sort_key. The primary key in a standard table must not be unique. The secondary key hash_key has the same components as the primary key and must be a unique hash key. The sorted key sort_key could also be defined as unique, but this is not beneficial in the example shown here, since a customer ID can appear more than once in the reservation table. The two syntax forms shown here differ in the specification of the name primary_key for the primary key, but they have the same meaning. Syntax form without the name primary_key specified: ABEXA 00739 Syntax form with the name primary_key specified: ABEXA 00740 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 The program DEMO_SECONDARY_KEYS demonstrates the declaration and use of a secondary table key and the resulting performance gains. ABAP_EXAMPLE_END • ALIAS TYPES, secondary_key
ABAP Addition
What does it do? An alias name alias_name can be defined for each secondary key of an internal table. The alias name is in the namespace of the secondary key, must comply with the naming conventions , and must be unique. It cannot be one of the predefined names primary_key or loop_key. It enables the secondary key to be addressed by means of an additional user-defined name. An alias name is part of the technical type properties of a table type. Two table types with otherwise identical technical properties, but different alias names, are not compatible.
Latest notes:
A secondary key with an alias name can be addressed by the alias name alias_name as well as by its name key_name.
An alias name can be used when changing the secondary keys of an existing table type in order to avoid the invalidation of existing users. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Definition of a secondary key carrname with an alias name carriername. Both names can be used in the USING KEY addition of a LOOP statement. ABEXA 01472 ABAP_EXAMPLE_END
