Skip to content

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

DATA - key

Short Reference

Other versions: 7.31 | 7.40 | 7.54


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



2. ... EMPTY KEY

Alternative 1



Defines the primary table key of an internal table by specifying components or as a standard key. The syntax and semantics of the additions are the same as for the TYPES statement for dedicated table types, with the difference that the primary key of a bound table type must always be specified completely:

  • For standard tables only the NON-UNIQUE KEY addition can be specified. If uniqueness is not specified, this is added implicitly. The addition UNIQUE KEY cannot be specified.
  • For sorted tables, one of the two additions UNIQUE KEY or NON-UNIQUE KEY must be specified.
  • For hashed tables, the UNIQUE KEY addition must be specified.

If no primary key is specified for DATA using WITH, the addition WITH NON-UNIQUE DEFAULT KEY is added implicitly for standard tables. This gives the table a standard key, which can be empty. In sorted tables and hashed tables, the primary key must be specified explicitly and cannot be empty.

If the name of the primary key primary_key is specified explicitly, the WITH HEADER LINE addition can no longer be specified, even outside the classes.


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. In particular, make sure that the declaration of the standard key is not added by mistake because the key has not been specified explicitly.

Alternative 2



Defines an empty primary key in an internal table. This variant is possible for standard tables only. The syntax and semantics are the same as for the statement TYPES.


  • The addition EMPTY KEY can clarify situations where the definition of a table key is not important.
  • We generally recommend EMPTY KEY instead of not specifying a key definition, since otherwise the standard key is used, which can often lead to unexpected results.