Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Declarations →  Declaration Statements →  Data Types and Data Objects →  Declaring Data Types →  TYPES →  TYPES - TABLE OF →  TYPES - tabkeys 

TYPES - secondary_key

Quick 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 using UNIQUE HASHED that are associated with table rows using a hash algorithm
  • Unique secondary sorted keys defined using UNIQUE SORTED that are associated with table rows using a secondary table index (in which the key fields are sorted in ascending order)
  • Non-unique secondary sorted keys defined using NON-UNIQUE SORTED that are associated with 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 specified after KEY. The row type must be structured and the components cannot be table types nor can they contain table types as components.
  • If the whole table row is to be defined as a key, the pseudo component table_line can be specified 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 using the statements READ TABLE itab, LOOP AT itab, MODIFY itab, and DELETE itab or in reads using table expressions and in mesh types and mesh paths, a secondary key can be used to specify 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 statement INSERT itab 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 statement APPEND.
  • 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 specified 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 (which can be hidden using a pragma).
  • 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 explicitly specifying the key used for LOOP processing.
  • Key fields can also have reference types. However, particularly for sorted keys this is not recommended, as sorting reference variables is questionable. For non-initial invalid references, no order is defined. A runtime error occurs if such a reference has to be compared within the framework of a key access.
  • 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, the executable example Deleting Rows Using Keys.


Example

Defines 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 of benefit in the example shown here, since a customer ID can appear more than once in the reservation table. The two syntax forms shown here differ by either specifying the name primary_key for the primary key or not specifying it. They do, however, have the same meaning.

Syntax form without the name primary_key specified:

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

Syntax form with the name primary_key specified:

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 program DEMO_SECONDARY_KEYS demonstrates the declaration and use of a secondary table key and the resulting performance gains.