Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Declarative statemnts →  Data Types and Data Objects →  Declaring Data Types →  TYPES →  TYPES - TABLE OF →  TYPES - tabkeys 

TYPES - secondary_key

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... {UNIQUE HASHED}|{UNIQUE SORTED}|{NON-UNIQUE SORTED} 
    KEY key_name COMPONENTS comp1 comp2 ... .

Effect

Defines a secondary table key with an internal table type. An internal table can have up to 15 secondary keys.

Types of Secondary Keys

Secondary keys are split into three types based on the type of access and their uniqueness:

  • Unique secondary hash keys defined with UNIQUE HASHED that are linked to table rows using a hash algorithm
  • Unique secondary sorted keys defined with UNIQUE SORTED that are linked to table rows using a secondary table index (in which the key fields are sorted in ascending order)
  • Unique secondary sorted keys defined with UNIQUE SORTED that are linked to table rows using a secondary table index (in which the key fields are sorted in ascending order).

Names of Secondary Keys

Each secondary key has a unique name with which it can be addressed. The name must be specified directly as key_name and must comply with the naming conventions. The name specified cannot be one of the predefined names primary_key or loop_key. In addition, the names of secondary keys and any alias name used for the primary key must be unique.

Key Fields

The key fields of the secondary key can be defined in the following ways; the order is significant:

  • Individual components comp1 comp2 ... of the row type are listed after KEY. The row type must be structured and the components cannot be table types nor can they contain table types as components.
  • If you want to define the whole table row as a key, you can declare the pseudo component table_line as the only component comp after KEY. This is possible for all row types that are not table types or that do not contain table types as components.

In an operation that changes the content of individual rows of an internal table, the key fields of a secondary table key are read-only only if the secondary key is used during this operation.

Programming Guideline

Use secondary keys in a way that benefits the table.


Notes

  • When internal tables are accessed with the statements READ TABLE itab, LOOP AT itab, MODIFY itab, and DELETE itab, a secondary key can be used to determine the rows to be processed or the processing order. To do this, the additions WITH [TABLE] KEY ... COMPONENTS or USING KEY must be specified. A secondary key is never used implicitly.
  • The INSERT itab statement determines the insert position using the primary key and primary index only. A secondary key can be specified only for the source table from which multiple rows are copied. The latter also applies to the APPEND statement.
  • A secondary key is never generic. When it is defined, all secondary fields and the uniqueness must be specified fully. An internal table type can, however, be generic with respect to its number of secondary keys.
  • DEFAULT KEY cannot be declared for secondary keys.
  • Structured components in particular can be specified as key fields, provided that the components meet the other requirements. When a structured key field is evaluated, the rules for structure comparisons apply.
  • If different table keys for an internal table contain the same components, the syntax check issues a warning.
  • With the exception of the restrictions outlined above, you can name secondary keys as you wish, but should make sure that you do not use the component names of the internal table. The name loop_key is reserved for the explicit declaration of the key used for LOOP processing.
  • The internal management of secondary keys in an internal table can involve significant memory consumption and updates. For this reason, secondary keys should be used sparingly and only implemented if their benefits outweigh the costs. See, for example, Deleting Rows Using Keys.


Example

Definition of a table type with a primary key and two secondary keys hash_key and sort_key. The primary key in a standard table cannot be unique. The secondary key hash_key has the same components as the primary key and must be a unique hash key. The sorted key sort_key could also be defined as unique, but this is not beneficial in the example shown here, since a customer ID can appear more than once in the reservation table.

TYPES sbook_tab 
      TYPE STANDARD TABLE 
      OF sbook 
      WITH NON-UNIQUE KEY primary_key 
           COMPONENTS carrid connid fldate bookid 
      WITH UNIQUE HASHED KEY hash_key 
           COMPONENTS carrid connid fldate bookid 
      WITH NON-UNIQUE SORTED KEY sort_key 
           COMPONENTS customid.

Example

The DEMO_SECONDARY_KEYS program demonstrates the declaration and use of a secondary table key and the resulting performance gains.