SAP NetWeaver AS ABAP Rel ease 702, Copyri ght 2010 SAP AG. Al l ri ghts reserved.

ABAP Keyword Documentation ABAP - Ref erence 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.
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 DELETE ADJACENT DUPLICATES statement is executed and the primary table key is empty, no rows
are deleted.
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.