..

USING KEY keyname

Effect

The addition USING KEY can be used to specify a table key keyname with which the processing is
carried out. The specified table key influences the order in which the table rows are accessed, and the
evaluation of the remaining conditions.

If the primary table key is specified using the name primary_key, the processing behaves in the same
way as when no key is explicitly specified. If a secondary table key is specified, the order in which the
rows are accessed is as follows:

• Specification of a sorted key

The rows are processed by ascending row number in the secondary table index In each loop
pass, the system field sy-tabix contains the row number of the current row in the associated
secondary table index.

• Hash key specified

The rows are processed in the order in which they were inserted into the table. In each loop
pass, the system field sy-tabix contains the value 0.

Notes

• Unlike the processing of a hashed table when a primary key is used, a preceding sort using the
statement SORT has no influence on the processing order when a secondary hash key is
specified.

• If a secondary table key is specified, any WHERE condition also specified must be optimizable.
Otherwise a syntax error occurs or an exception is raised.

Example

See Loop Across Internal Table with Key Specified .

Addition 2

... [FROM idx1] [TO idx2]

Effect

If these additions are used, only the table rows from row number idx1, or up to row number idx2, are
respected if the table index used. If only FROM is specified, all rows of the table from row
number idx1 up to and including the last row are taken into account. If only TO is specified, all rows in
the table from the first row up to row number idx2 are respected.

If the addition USING KEY is not used, or the primary table key is specified in keyname, the
additions FROM and TO can only be used for index tables. In this case, they refer to the row numbers of
the primary table index.

If a sorted secondary key is specified in keyname after USING KEY, the additions FROM and TO can be
used for all table categories and refer to the row numbers of the secondary table index.
idx1 and idx2 are numeric expression positions of operand type i. The following restrictions apply:

• If the value of idx1 is less than or equal to 0, it is set to 1 in the statement LOOP. If the value
of idx1 is greater than the total number of table rows, no processing takes place.

• If the value of idx2 is less than or equal to 0, the statement LOOP is not executed. If the value
of idx2 is greater than the number of table rows, it is set to the number of table rows.

• If the value of idx2 is less than the value of idx1, no processing takes place.

The value of idx1 is evaluated once when the loop is entered. Any changes to idx1 during loop
processing are ignored. In contrast, the value of idx2 is evaluated in each loop pass and any changes
made to idx2 during loop processing are respected.

Note

To determine when loop processing is exited and whether the value specified in idx2 has been reached,
the current row number is evaluated. Note that this number can be changed if rows are inserted or
deleted during a loop pass as described in LOOP. As a result, there may be more loop passes (if rows are
inserted) or fewer loop passes (if rows are deleted) than is specified by the difference
between idx2 and idx1.

Addition 3

... WHERE log_exp

Effect

Static WHERE condition. All rows are processed for which the condition after WHERE is met. If a
static WHERE condition is specified, the row type of the internal table must be statically
identifiable. WHERE can be specified for all table categories.

A logical expression log_exp can be specified after WHERE, in which the first operand of each relational
expression is a component of the internal table. Any comparison expression and the predicate
expression IS INITIAL can be specified as relational expressions. Other predicates cannot be
specified. The components of the internal table must be specified as individual operands and not as part
of an expression. Parenthesized character-like data objects cannot be used to specify a component
dynamically here. The remaining operands of a relational expression are general expression positions at
which any suitable individual operands or expressions can be specified, but no components of the
internal table. The specified components can have any data type. The relevant comparison rules apply to
the evaluation.

• When standard tables are accessed without a secondary key being specified, the access is not
optimized. This means that all rows of the internal table are tested for the logical expression of
the WHERE addition.

• When using a sorted key or a hash key (that is, when accessing a sorted table, a hashed table,
or a secondary table key), an attempt is made to optimize the access as described
under Optimization of the WHERE Condition. If the following prerequisites are not met:

o the entire logical expression (or a part of the expression) can be transformed to a key
access,
 o the transformable part of the logical expression has the same result as the resulting key
access,

no optimization takes place when a sorted table or a hashed table is accessed using the primary
table key. Any access using a secondary table key produces a syntax error or exception. In the
part of the logical expression relevant for the optimization, the static WHERE condition cannot
specify any duplicate or overlapping keys. Duplicate key components can, however, be specified
in the part of the logical expression whose relational expressions do not make a contribution to
the optimized access.

Notes

• When using a WHERE condition, note that the comparison rules for incompatible data types apply
when comparing incompatible data objects. Here, the data types involved determine which
operand is converted. If the additions WITH TABLE KEY and WITH KEY of the
statement READ are used or if the appropriate keys are specified in table expressions, however,
the content of the specified data objects is always converted to the data type of the columns
before the comparison. This can produce varying results.

• If possible, all operands of the logical expression should be in compatible pairs, so enabling
the WHERE condition to be optimized.

• If a comparison expression with a selection table is specified after IN as a logical expression,

note that the expression at the initial table is always true and then all rows are edited.

• The logical expression declared after WHERE is evaluated once when the loop is entered. Any
changes to the second operand during loop processing are ignored.