ABAP Alternative 1 ... $[UNIQUE$|NON-UNIQUE$] ${KEY ...$}$|${DEFAULT KEY$}
ABAP Addition 1 ... primary_key COMPONENTS 2 ... ALIAS alias_name
What does it do? Definition of the primary table key of a table type by specifying components or by specifying it as a standard key. Name of the Primary Key Like secondary keys, the primary key also has a name with which it can be addressed. This name cannot be freely selected and is specified as primary_key instead. It does not have to be explicitly specified when the table is defined since it is always set implicitly. However, it can also be specified before the addition COMPONENTS. Key Fields The key fields of the primary 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. For elementary line types, table_line is the only component that can be specified.
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. For structured line types, table_line works like a listing of each individual component.
Specification of the standard key DEFAULT KEY. The standard key fields of a structured line type are all fields with a non-numeric elementary data type. The standard key for non-structured line types is the entire table line if the line type itself is not a table type. If there is no corresponding component or if the line type is itself a table type, the standard key is empty, which is only possible for standard tables. The key fields of the primary table key are generally read-only in all operations that change the content of individual lines of a sorted table or hashed table. Uniqueness of the Primary Key The specifications UNIQUE or NON-UNIQUE determine the uniqueness of the primary table key. In the case of a primary table key specified with UNIQUE, a line with specific content of the key fields can occur only once in an internal table of this type. Only NON-UNIQUE can be used for standard tables. UNIQUE must be used for hashed tables and both can be specified for sorted tables. Uniqueness does not have to be specified, which makes the table type partially generic with respect to the entry of the primary key. The table type can then only be used for typing of formal parameters or field symbols. The table categories differ as follows:
The addition NON-UNIQUE is added implicitly for types for standard tables. A standard table is never generic with respect to uniqueness.
Types for sorted tables can be completely generic with respect to uniqueness.
Types for hashed tables can be completely generic with respect to uniqueness, but a concrete hashed table always has a unique primary key.
Uniqueness cannot be specified for the generic table categories ANY TABLE or • TABLE.
Latest notes:
The declaration of the primary table key as a standard key can be critical for various reasons. Instead, key fields should be specified explicitly.
Structured components can be explicitly specified when specifying key fields, provided that the components meet the other requirements. When a structured key field is evaluated, the rules for structure comparisons apply.
Key fields can also have reference types . However, this is not recommended particularly for sorted keys, since 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 addition DEFAULT KEY must not be confused with the addition EMPTY KEY. A standard key declared using the addition DEFAULT KEY can be empty unexpectedly in a standard table, whereas EMPTY KEY declares explicitly empty primary table keys explicitly for tables with any line types.
Static boxes and their components can be key fields of internal tables. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Definition of a primary key without explicit name specification. The statement has the same meaning as in the following example. ABEXA 00732 ABAP_EXAMPLE_END
ABAP Addition
What does it do? If the key fields are defined by specifying components, the name of the primary key can be specified explicitly in the statement TYPES . However, the predefined name primary_key must be specified for primary_key. The addition COMPONENTS must then also be specified before the component is specified.
Latest notes: Explicitly specifying the name primary_key does not enable the predefined name primary_key to be changed but enables an alias name to be specified using the addition ALIAS. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Definition of a primary key with explicit name specification. The statement has the same meaning as in the previous example. ABEXA 00733 ABAP_EXAMPLE_END • ALIAS TYPES, key
ABAP Addition
What does it do? An alias name alias_name can be defined for the primary key in sorted tables and hashed tables, for as long as the primary key is not generic. 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 primary key to be addressed like a secondary key by means of a user-defined name. The syntax requires the name primary_key to be specified explicitly when defining an alias 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 primary key with an alias name can be addressed by the alias name alias_name as well as by the predefined name primary_key. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Definition of a primary key with an explicit name specification and its use in a table expression. ABEXA 00734 ABAP_EXAMPLE_END • EMPTY KEY TYPES
ABAP Alternative 2 ... EMPTY KEY
What does it do? Definition of an empty primary key of a table type. This variant is only possible for standard tables. An empty table key does not contain any key fields.
Latest notes:
When an empty table key is defined explicitly, this means that the internal table is to be handled like an array in which there is no order specified by key values.
The order of a standard table with an empty primary key is determined primarily by the primary index. There are no restrictions on related index accesses and loop processing.
In statements that evaluate the primary table key to identify lines to be processed, an empty table key generally produces unexpected behavior and therefore a syntax check warning. For a list of these statements, see Empty Table Key.
A table key where EMPTY KEY is used to declare an empty table key explicitly is not generic with respect to its primary key. This means that the addition EMPTY KEY can be used to prevent a table type from being too generic with respect to its primary key.
The explicit declaration of an empty table key using EMPTY KEY is independent of the line type.
A standard table with an empty primary key can have non-empty secondary keys.
Empty table keys can also be created implicitly when the standard key is used for standard tables. If an empty table key is required, it is preferable to declare it explicitly using EMPTY KEY. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The table in the example below is only intended for loop processing in which all lines of the table are processed in a random order. ABEXA 01695 ABAP_EXAMPLE_END
