table_exp - itab_line
ABAP Syntax ... { [KEY keyname INDEX] idx
}
| { comp1 = operand1
comp2 = operand2 ... }
| { KEY keyname [COMPONENTS]
{comp_name1|(name1)} = operand1
{comp_name2|(name2)} = operand2
... } ...
ABAP_ALTERNATIVES:
1 ... [KEY keyname INDEX] idx
2 ... comp1 = operand1 comp2 = operand2 ...
3 ... KEY keyname [COMPONENTS] ...
Effect
Specifies a table row in the square brackets of a
table expression . This makes three
alternatives possible:
Index read
Read using a free key
Read using a table key
Note
The square brackets shown here indicate the optional additions and are
not part of the syntax.
Example
See Table Expressions, Specified Rows
.
ABAP_ALTERNATIVE_1 ... [KEY keyname INDEX] idx
Effect
The table expression reads the row with the row number specified in
idx with respect to a table index. The row is read in exactly the
same way as when specifying an index,
INDEX idx [USING KEY keyname] , in the statement
READ TABLE . Similarly, idx is a
numeric expression position
and the optional KEY keyname INDEX is equivalent to the USING
KEY keyname specified. If the optional addition is not used, itab
must be an index table . If the
addition is used, the secondary table index of a sorted secondary key
can be specified statically or dynamically.
If no row is found for the specified index, the handleable exception
CX_SY_ITAB_LINE_NOT_FOUND is usually raised. Exceptions to this
rule are uses in the statement
ASSIGN , in the predicate function
line_exists , and in the table
function line_index .
ABAP_ALTERNATIVE_2 ... comp1 = operand1 comp2 = operand2 ...
Effect
The table expression reads the row in accordance with the specified free
search key. The search is performed in exactly the same way as when
specifying the free search key comp1 =
operand1 comp2 = operand2 ... in the statement
READ TABLE . Similarly, the components
comp1 comp2 ... can be specified in accordance with the rules from
the section Specifying Components . Also,
compatible or convertible operands operand1 operand2 ... must be
specified that are general
expression positions .
If no row is found for the specified free key, the handleable exception
CX_SY_ITAB_LINE_NOT_FOUND is usually raised. Exceptions to this
rule are uses in the statement
ASSIGN , in the predicate function
line_exists , and in the table
function line_index .
Notes
If the free key overlaps with some or all of the
primary table key , the
optimizations described under READ TABLE
are performed when sorted tables and hashed tables are read.
Unlike the statement READ TABLE with a
free key specified , no binary searches can
be forced for a table expression and it is not possible to specify
explicit table key for optimizing searches using secondary keys.
ABAP_ALTERNATIVE_3 ... KEY keyname [COMPONENTS] ...
Effect
The table expression reads the row in accordance with the explicitly
specified table key .
Generally, the search is performed in exactly the same way as when
specifying the table key WITH TABLE KEY
[keyname COMPONENTS] ... in the statement
READ TABLE . The table key must be covered completely by specifying
component and no components can be specified that are not part of the
table key.
If the table expression is specified as an argument of the
predicate function
line_exists or of the table
function line_index , the search
is performed as when specifying a free search key
WITH KEY keyname COMPONENTS ... in
the statement READ TABLE and the key is
joined with a table key. A sorted table key does not have to be covered
in full by specified components. For both categories of secondary keys,
components can be specified that are not part of the table key.
Unlike the statement READ TABLE , a table expression must specify
the name of the table key and the addition COMPONENTS can be
omitted. Like here, the table key keyname and the key components
can be specified statically or dynamically. The operands operand1
operand2 ... are general
expression positions .
If no row is found for the specified table key, the handleable exception
CX_SY_ITAB_LINE_NOT_FOUND is usually raised. Exceptions to this
rule are uses in the statement
ASSIGN , in the predicate function
line_exists , and in the table
function line_index .
Notes
Before the primary table key can be
used explicitly in this variant, the key must first be specified using
its predefined name primary_key or an alias name.
Searches using the primary table key
do not have to specify it explicitly. Instead, the variant with a
free search key can be used. If this covers the primary table key, it is
used for optimized reads on sorted tables and hashed tables.
The differing behavior of the specified key outside and inside the
functions line_exists and
line_index is explained as
follows:
Outside the functions, the main purpose of an explicitly specified table
key is to read precisely one fully specified row.
Within the functions, the existence of a specified row (not necessarily
specified in full) or, for example, a row number as the starting point
of a subsequent sequential read using
LOOP ... FROM is to be determined as efficiently as possible.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved