SAP TYPES SECONDARY KEY ABAP Statements

Get Example source ABAP code based on a different SAP table
  



TYPES - secondary_key

Short Reference

• KEY TYPES
• UNIQUE HASHED KEY TYPES
• UNIQUE SORTED KEY TYPES
• NON-UNIQUE SORTED KEY TYPES
• COMPONENTS TYPES


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

What does it do? 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 the whole table row is to be defined as a key, the pseudo component table_line can be declared 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.

ABAP_PGL Use secondary keys in a way that benefits the table.

Latest notes:When internal tables are accessed with the statements READ TABLE itab, LOOP AT itab, MODIFY itab, and DELETE itab or in reads using table expressions, 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 ABAP Coding
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 ABAP Coding
The DEMO_SECONDARY_KEYS
program demonstrates the declaration and use of a secondary table key and the resulting performance gains.

Return to menu