TYPES - key
Short Reference
ABAP Syntax ... { [UNIQUE | NON-UNIQUE]
{ {KEY [primary_key [ALIAS key_name] COMPONENTS] comp1 comp2
...}
| {DEFAULT KEY} }}
| { EMPTY KEY } ... .
ABAP_ALTERNATIVES:
1 ... [UNIQUE|NON-UNIQUE] {KEY ...}|{DEFAULT KEY}
2 ... EMPTY KEY
ABAP_ALTERNATIVE_1 ... [UNIQUE|NON-UNIQUE] {KEY ...}|{DEFAULT
KEY}
ABAP_ADDITIONS:
1 ... primary_key COMPONENTS
2 ... ALIAS key_name
What does it do? Defines the primary
table key of an internal table by specifying components or as a
standard key.
Name of the Primary Key
Like secondary keys , the primary key
also has a name with which it is addressed. This name cannot be freely
selected and is predefined as "primary_key". It does not have to be
explicitly specified when the table is defined since it is always set
implicitly. However, it can also be specified before the COMPONENTS
addition.
Key Fields
The key fields of the primary 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. For elementary row types, table_line is the only
component that can be specified.
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. For structured row types,
table_line operates like a listing of each individual component.
Specifying the standard key
DEFAULT KEY . The standard key fields of a structured row type are all
fields with non-numeric elementary data type. The standard key for
non-structured row types is the entire table row, if the row type itself
is not a table type. If there is no corresponding component or if the
row type is itself a table type, the standard key is
empty � this applies to standard tables only.
The key fields of the primary table key are generally read-only in all
operations that change the content of individual rows of a sorted table
or hash table.
Uniqueness of the Primary Key
The UNIQUE or NON-UNIQUE declarations specify the
uniqueness of the primary table key. In the case of a primary table key
specified with UNIQUE , a row with specific content of the key
fields can appear only once in an internal table of this type. Only
NON-UNIQUE can be used for standard
tables ; UNIQUE must be used for
hash tables ; both can be declared for
sorted tables .
The uniqueness declaration can be omitted, which makes the table type
partially generic with respect to the primary key declaration. The table
type can then only be used for typings of
formal parameters or field symbols. The differences between the table
categories are as follows:
The NON-UNIQUE addition is extended implicitly for types for
standard tables. A standard table is never generic with respect to
uniqueness.
Types for sorted tables can be completely generic with respect to
uniqueness.
Types for hash tables can be completely generic with respect to
uniqueness; a fixed hash table, however, always has a unique primary
key.
No uniqueness declaration can be made for the generic table categories
ANY TABLE or INDEX TABLE .
Latest notes: The declaration of the primary table key as a
standard key can be
critical for various reasons. We recommend
that the key fields are specified explicitly instead.
Structured components in particular can be explicitly 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.
Note that the addition DEFAULT KEY must not be confused with
the addition EMPTY KEY . A standard key declared using the
addition DEFAULT KEY can be empty
unexpectedly in a standard table, whereas EMPTY KEY declares
empty primary table keys explicitly for tables with any row types.
Static boxes and their components can be
key fields of internal tables.
Example ABAP Coding Defines a primary key without an explicitly specified
name. The statement has the same meaning as in the following example.
TYPES sbook_tab
TYPE SORTED TABLE
OF sbook
WITH UNIQUE KEY carrid connid fldate bookid.
ABAP_ADDITION_1 ... primary_key COMPONENTS
What does it do?
If the key fields are defined by specifying components, the name of
the primary key can be specified explicitly in the TYPES
statement. However, the predefined name "primary_key" must be specified
for primary_key . The COMPONENTS addition must then also be
specified before the component is specified.
Latest notes: Explicitly specifying the name primary_key does not
enable predefined name "primary_key" to be changed, but does enable an
alias name to be specified by using the addition ALIAS .
Example ABAP Coding Defines a primary key with an explicitly specified name.
The statement has the same meaning as in the previous example.
TYPES sbook_tab
TYPE SORTED TABLE
OF sbook
WITH UNIQUE KEY primary_key
COMPONENTS carrid connid fldate bookid.
ABAP_ADDITION_2 ... ALIAS key_name
What does it do? An alias name key_name can be defined for the
primary key when using sorted tables and hash tables, as long as the
primary key is not generic. The alias name is in the namespace of the
secondary key, must comply with the naming
conventions , and must be unique. It enables the primary key to be
addressed like a secondary key by means of a self-defined name.
The syntax requires the name primary_key to also be declared
explicitly in the definition of the alias name.
ABAP_ALTERNATIVE_2 ... EMPTY KEY
What does it do? Defines an empty primary key
of a table type. This variant is possible for standard tables only. An
empty table key does not contain any key fields.
Latest notes: When an empty table key is defined explicitly, this means
that the internal table is to be handled like an array that is
not subject to being ordered by key values.
The ordering of a standard table with an empty primary key is
determined for the most part by the
primary index . There are no restrictions on related index accesses
and loop processing.
In statements that evaluate the primary table key to identify rows, an
empty table key generally produces unexpected behavior and a syntax
check warning. For a list of these statement, see
Empty Table Key .
A table key where EMPTY KEY is used to declare an empty table
key explicitly is not generic with respect to its primary key. This
means that the addition EMPTY KEY can be used to prevent a table
type from being too generic with respect to its primary key.
The explicit declaration of an empty table key using EMPTY KEY
is independent of the row type.
A standard table with an empty primary key can have non-empty
secondary keys .
Empty table keys can also be created implicitly when the
standard key is used for standard tables.
If an empty table key is to be used, however, it is better to declare it
explicitly using EMPTY KEY .
Example ABAP Coding The table in the example below is only intended for a
loop in which all rows of the table are processed in a random order.
TYPES addresses TYPE STANDARD TABLE OF scustom-email WITH EMPTY KEY.
DATA email_tab TYPE addresses.
FIELD-SYMBOLS <(><<)>email> LIKE LINE OF email_tab.
...
SELECT email
FROM scustom
INTO TABLE email_tab.
...
LOOP AT email_tab ASSIGNING <(><<)>email> USING KEY primary_key.
mail_manager->send( address = <(><<)>email> text = ... ).
ENDLOOP.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved