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

Empty Table Key

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

• Declaration

• Notes on Use

• Uncritical use

• Critical use

• Example

Other versions: 7.31 | 7.40 | 7.54

Note

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

Declaration

An empty primary table key can be created as follows:

• Explicitly with the addition EMPTY KEY of the statements TYPES, DATA, and so on.

• Explicitly using an inline declaration INTO TABLE @DATA(itab) in the statement SELECT

• Implicitly when using the standard key if a structured row type does not contain any non-numeric elementary components or if an unstructured row type is table-like.

Notes on Use

Uncritical use

An empty primary table key can be used to handle a table like an array. This means that filling the table and other access do not rely on an order determined by key values. In this case, an empty internal table key can be used in all statements that determine (implicitly or explicitly) the order in which the internal table is accessed.

Notes

• Developers should always be aware of the fact that they are handling an empty primary table key. This is really achieved only when the empty key is declared explicitly. This implicit declaration using the standard key (in which the row type determines whether the primary table key is empty or not) is not usually suitable.

• Even an empty primary key in a standard table has the order specified by the primary index, which can be exploited in related index accesses or loops.

Example

A particularly prominent example is the statement LOOP AT itab, which when used implicitly or explicitly (using USING primary_key) defines the processing order with respect to the primary table index, but is otherwise ignored.

Critical use

In the following statements, which work with the primary table key without specifying the key fields explicitly, specifying an empty primary table key is critical and generally produces unexpected behavior. An empty table key that is known statically produces a syntax check warning.

• Primary table key specified by a work area:

• If FROM wa is used to specify an empty table key for the statement READ TABLE, the first row of the internal table is read.

• If FROM wa is used to specify an empty table key for the statement MODIFY, the first row of the internal table is modified.

• If FROM wa is used to specify an empty table key for the statement DELETE, the first row of the internal table is deleted.

• If the statement SORT itab is executed without the addition BY and the primary table key is empty, the statement is ignored and the table is not sorted.

• If the statement DELETE ADJACENT DUPLICATES is executed and the primary table key is empty, no rows are deleted.

• If the primary table key is empty and the statement COLLECT is executed, the first row of the internal table is compressed. In this case, all components of the row type must be numeric.

Note

The statements described above can be particularly unpredictable when using the standard key (which itself can be declared implicitly) to declare an empty internal table key.

Example

Example

Typical use of a table with an empty table key, in which the order of the rows should not be changed by sorting. A SORT source statement would have no effect.

DATA source 
  TYPE STANDARD TABLE OF string 
       WITH EMPTY KEY. 

READ REPORT 'DEMO_TAB_EXP_LINE' INTO source. 

cl_demo_output=>display( source ).