SAP ITAB EMPTY KEY



Get Example source ABAP code based on a different SAP table
  



ABAP_ITAB - Empty Table Key
The primary table key of a standard table can be empty. An empty table key does not contain any key fields.
ITOC



Latest notes:

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

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$|@FINAL(itab) in the statement SELECT
Implicitly, when using the standard key if a structured line type does not contain any non-numeric elementary components or if an unstructured line 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 accesses take place in such a way that no order is based on key values. In this case, an empty internal table key can be used in all statements in which its implicit or explicit specification determines the order in which the internal table is accessed.



Latest notes:

Developers should always be aware that they are handling an empty primary table key. This can only be achieved when the empty key is declared explicitly. An implicit declaration using the standard key, in which the line 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 loop processing.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
A prominent example is the statement LOOP AT itab, where implicit or explicit use (using USING primary_key) defines the processing order with respect to the primary table index, but has no other effect.
ABAP_EXAMPLE_END

Critical Use
In the following statements, which work with the primary table key without specifying the key fields explicitly, the specification of 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 specification using a work area:
If FROM wa is used to specify an empty table key for the statement READ TABLE, the first line of the internal table is read.
If FROM wa is used to specify an empty table key for the statement MODIFY, the first line of the internal table is modified.
If FROM wa is used to specify an empty table key for the statement DELETE, the first line 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, which means no sorting takes place.
If the statement DELETE ADJACENT DUPLICATES contains an empty primary table key, no lines are deleted.
If the primary table key is empty, the statement COLLECT always compresses the first line of the internal table. In this case, all components of the line type must be numeric.



Latest notes:

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.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX
Typical use of a table with an empty table key, in which the order of the lines should not change due to sorting. A SORT source statement would have no effect.
ABEXA 01058
ABAP_EXAMPLE_END

ABAP_EXAMPLE_V5
Use of a table with an empty table key, in which the order of the lines should not change due to sorting. A SORT table_of_strings statement would have no effect.
ABEXA 01705
ABAP_EXAMPLE_END