ABAP Keyword Documentation → ABAP − Reference → Processing Internal Data → Internal Tables → Internal Tables - Overview → Table Keys → Primary Table Keys
Standard Key
The standard key is a special primary table key in an internal table.
Other versions: 7.31 | 7.40 | 7.54
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, 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, 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 additionDEFAULT 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 statementDATA
.
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 potential for empty standard keys in standard tables often causes unexpected behavior too. 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,
the primary key must not be set as the standard key by mistake, the key must not be forgotten in declarations
of standard tables using DATA
, and that the generic table type must not be used unknowingly.
Example
Example
Internal table with standard key. In the structure SCARR, all five components meet the requirements for the standard key and are used as key fields. In a key access using a table expression, the syntax check requires that each key field of the primary table key is specified.
DATA scarr_tab
TYPE HASHED TABLE OF scarr
WITH UNIQUE DEFAULT KEY.
...
DATA(scarr_line) =
VALUE #( scarr_tab[ KEY primary_key
mandt = sy-mandt
carrid = '...'
carrname = '...'
currcode = '...'
url = '...' ] OPTIONAL ).