LOOP AT itab - cond

Syntax

... [FROM idx1] [TO idx2] [WHERE log_exp].

Extras:

1. ... FROM idx1

2. ... TO idx2

3. ... WHERE log_exp

Effect

The table rows to be read in a LOOP-loop can be limited by optional conditions; if no conditions are specified , all rows of the table are read.

Addition 1

... FROM idx1

Effect

The specification FROM is only possible with standard tables and sorted tables. This specification only accepts table rows starting from table index idx1. For idx1, a data object of the type i is expected. If the value of idx1 is smaller or equal to 0, then it will be set to 1. If the value is larger than the number of table rows, the loop is not passed through.

Addition 2

... TO idx2

Effect

The specification TO is only possible with standard tables and sorted tables. The specification only accepts table rows after table index idx2. For idx2, a data object of the type i is expected. If the value of idx2 is smaller or equal to 0, then the loop will not be passed. If the value is larger than the number of table rows, then the value will be set to the number of rows. If idx2 is smaller than idx1, then the loop is not passed as well.

Addition 3

... WHERE log_exp

Effect

WHERE can be specified with all table-types. After WHERE, you can specify any logical expression log_exp in which the first operand of any singular comparison is a component of the internal table. For this reason, all logical expressions are possible except for IS ASSIGNED, IS REQUESTED and IS SUPPLIED. Dynamic specification of a component through bracketed character-type data objects is not possible. Loops at sorted tables must have compatible operands of the logical expression. All rows are read for which the logical expression is true.

Notes

• The logical expression specified after WHERE is analyzed once at entry into the loop. Possible changes of the second operand during loop processing are not taken into account.
  
• While with standard tables all rows of the internal table are checked for the logical expression of the WHERE- addition, with sorted tables and hash tables (as of Release 7.0) you can achieve optimized access by checking that at least the beginning part of the table key in sorted tables and the entire table key in hash tables is equal in the logical expression through queries linked with AND. Optimization also takes effect if the logical expression contains other queries linked with AND with arbitrary operators.