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 →
Standard Key
The standard key is a special primary table key in an internal table.
Key Fields of the Standard Key
The key fields of the standard key are defined as follows:
In tables with a structured row type, the standard key is formed from all components with character-like and
byte-like data types, with any substructures being expanded by elementary components. If the row type does
not contain components like these, then the standard key is empty for standard tables, meaning it does not
contain any key fields.
The standard key for tables with non-structured row types is the entire table row, if the row type itself is not
table-like. If the row type is table-like, then the standard key is empty for standard tables.
Empty standard keys are not possible for sorted tables and hashed tables, and an error occurs if an attempt is made
to create a key like this.
Notes
In tables with non-structured row types, the standard key can also have a numeric type or reference type; this
does not apply for the key fields if the row types are structured.
The static boxes of a structured row type are handled like regular components, with respect to the standard
key.
Declaration of the Standard Key
The standard key can be declared as follows:
Explicitly using the additions UNIQUE|NON-UNIQUE KEY of the statements TYPES, DATA and so on, with
the addition DEFAULT KEY being specified rather than a list of components.
Implicitly if no explicit primary key specification is made in the declaration of a standard table with the
statement DATA.
Implicitly, if a standard table type with a generic primary table key is specified behind TYPE in the statement
DATA.
Notes on Use
Using standard keys is critical for various reasons:
It is not usually enough to identify the key fields just by their data type and not their semantic properties. This
often leads to unexpected behavior in sorts and other access types.
The possibility of empty standard keys in standard tables also often causes unexpected behavior. For
example, using keys like this for sorting is useless, whereas a corresponding read finds the first row.
The standard key often contains too many key fields, leading to performance problems in key accesses.
If using the standard key and a structured row type, all character-like and byte-like fields of sorted tables and
hashed tables are read-only, which can cause unexpected runtime errors.
For this reason, declare the primary key by listing the components explicitly, if possible. In particular, you must
make sure that the primary key is not set as the standard key by mistake, that you do not forget to specify the key
in declarations of standard tables with DATA, and that you do not use a generic table type without realizing it.