Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing Internal Data →  Internal Tables →  Internal Tables - Overview →  Table Keys →  Primary Table Key 

Empty Table Key

The primary table key of a standard table can be empty. An empty table key does not contain any key fields.

Other versions: 7.31 | 7.40 | 7.54


Note

Sorted keys and hashed keys are never empty, regardless of whether they are primary or secondary.

Declaration

An empty primary table key can currently only be created implicitly if, when using the standard key, a structured row type does not contain any character-like or byte-like components or a unstructured row type is table-like.


Note

An explicit declaration using an addition EMPTY KEY for TYPES, DATA and so on is planned for a future release.

Notes on Usage

Non-critical usages

An empty primary table key can be used to handle a table like an array. This means that the table is filled and accessed without needing to be ordered by key values. An empty internal table key can be used in all statements where, if specified implicitly or explicitly, the key determines the order in which the internal table is accessed.


Notes

  • Developers must always be aware of exactly when they are dealing with an empty primary table key. This is actually only achieved by explicitly declaring the empty key, a feature planned for a future release. An implicit declaration using the standard key (where the row type determines whether the primary table key is empty or not) is not generally suitable.

  • For empty primary keys, there is also (in a standard table) always the order defined by the primary index, which can be exploited in index accesses or loops.


Example

A good example of this is the LOOP AT itab statement in which the implicit or explicit use (by means of USING primary_key) determines the processing sequence with respect to the primary table index, but otherwise has no impact.

Critical usages

If the primary table key is used to specify the lines to be edited, and this key is empty, this can result in unexpected behavior. This applies in the following cases in which the key fields are not explicitly specified:

  • When you specify the primary table key using a work area:
  • If an empty table key is specified using FROM wa with the READ TABLE statement, the first row of the internal table is read.
  • If an empty table key is specified using FROM wa with theMODIFY statement, the first row of the internal table is modified.
  • If an empty table key is specified using FROM wa with the DELETE statement, the first row of the internal table is deleted.
  • If the SORT itab statement is executed without the BY addition, and the primary table key is empty, the statement has no impact, that is, the data is not sorted.
  • If the COLLECT statement is executed and the primary table key is empty, the first row of the internal table is always compressed. In this case, all components of the line type must be numeric.


Note

Implicitly declaring an empty internal table key using the standard key, which can also be declared implicitly, can result in unexpected behavior when the statements outlined above are used.