TYPES - key - ABAP Keyword Documentation

ABAP - Keyword Documentation → ABAP - Reference → Declarations → Declaration Statements → Data Types and Data Objects → Declaring Data Types → TYPES → TYPES - TABLE OF → TYPES - tabkeys →

TYPES - key

Quick Reference

Syntax

... { [UNIQUE | NON-UNIQUE]
      { {KEY [primary_key [ALIAS key_name] COMPONENTS] comp1 comp2 ...}
      | {DEFAULT KEY} }  }
  | { EMPTY KEY } ...

Alternatives:

1. ... [UNIQUE|NON-UNIQUE] {KEY ...}|{DEFAULT KEY}

2. ... EMPTY KEY

Alternative 1

... [UNIQUE|NON-UNIQUE] {KEY ...}|{DEFAULT KEY}

Additions

1. ... primary_key COMPONENTS

2. ... ALIAS key_name

Effect

Defines the primary table key of an internal table by specifying components or as a standard key.

Name of the Primary Key

Like secondary keys, the primary key also has a name with which it is addressed. This name cannot be freely selected and is predefined as "primary_key". 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; the order is significant:

Individual components comp1 comp2 ... of the row type are specified after KEY. The row type must be structured and the components cannot be table types and cannot contain table types as components. For elementary row types, table_line is the only component that can be specified.
If the whole table row is to be defined as a key, the pseudo component table_line can be declared as the only component comp after KEY. This is possible for all row types that are not table types or that do not contain table types as components. For structured row types, table_line operates like a listing of each individual component.
Specifying the standard key DEFAULT KEY. The standard key fields of a structured row type are all fields with non-numeric elementary data type. The standard key for non-structured row types is the entire table row, if the row type itself is not a table type. If there is no corresponding component or if the row type is itself a table type, the standard key is empty – this applies to standard tables only.

The key fields of the primary table key are generally read-only in all operations that change the content of individual rows of a sorted table or hashed table.

Uniqueness of the Primary Key

The UNIQUE or NON-UNIQUE declarations specify the uniqueness of the primary table key. In the case of a primary table key specified with UNIQUE, a row with specific content of the key fields can appear 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; both can be declared for sorted tables.

The uniqueness declaration can be omitted, which makes the table type partially generic with respect to the primary key declaration. The table type can then only be used for typings of formal parameters or field symbols. The differences between the table categories are as follows:

The addition NON-UNIQUE is expanded implicitly in the case of 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; a fixed hashed table, however, always has a unique primary key.
No uniqueness declaration can be made for the generic table categories ANY TABLE or INDEX TABLE.

Notes

The declaration of the primary table key as a standard key can be critical for various reasons. It is best to specify key fields explicitly instead.
Structured components in particular can be explicitly 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.
Note that 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 empty primary table keys explicitly for tables with any row types.
Static boxes and their components can be key fields of internal tables.

Example

Defines a primary key without an explicitly specified name. The statement has the same meaning as in the following example.

TYPES sbook_tab
      TYPE SORTED TABLE
      OF sbook
      WITH UNIQUE KEY carrid connid fldate bookid.

Addition 1

... primary_key COMPONENTS

Effect

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.

Note

Explicitly specifying the name primary_key does not enable predefined name "primary_key" to be changed, but does enable an alias name to be specified by using the addition ALIAS.

Example

Defines a primary key with an explicitly specified name. The statement has the same meaning as in the previous example.

TYPES sbook_tab
      TYPE SORTED TABLE
      OF sbook
      WITH UNIQUE KEY primary_key
           COMPONENTS carrid connid fldate bookid.

Addition 2

... ALIAS key_name

Effect

An alias name key_name can be defined for the primary key when using sorted tables and hashed tables, 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 enables the primary key to be addressed like a secondary key by means of a self-defined name.

The syntax requires the name primary_key to also be declared explicitly in the definition of the alias name.

Alternative 2

... EMPTY KEY

Effect

Defines an empty primary key of a table type. This variant is possible for standard tables only. An empty table key does not contain any key fields.

Notes

When an empty table key is defined explicitly, this means that the internal table is to be handled like an array that is not subject to being ordered by key values.
The ordering of a standard table with an empty primary key is determined for the most part 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 rows, an empty table key generally produces unexpected behavior and 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 row 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 to be used, however, it is better to declare it explicitly using EMPTY KEY.

Example

The table in the example below is only intended for a loop in which all rows of the table are processed in a random order.

TYPES addresses TYPE STANDARD TABLE OF scustom-email WITH EMPTY KEY.

DATA  email_tab TYPE addresses.

FIELD-SYMBOLS <email> LIKE LINE OF email_tab.

...

SELECT email
       FROM scustom
       INTO TABLE @email_tab.

...

LOOP AT email_tab ASSIGNING <email> USING KEY primary_key.
  mail_manager->send( address = <email> text = ... ).
ENDLOOP.