ABAPLOOP_AT_ITAB_COND - LOOP AT ITAB COND

Addresses (Business Address Services)   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

LOOP AT itab - cond

Short Reference

Syntax

... [USING KEY keyname] [FROM idx1] [TO idx2] [WHERElog_exp|(cond_syntax)] ... .

Additions

1. ... USING KEY keyname

2. ... [FROM idx1] [TO idx2]

3. ... WHERE log_exp

4. ... WHERE (cond_syntax)

Effect

USING KEY keynameis used to determine the table key with which the loop is executed. The table rows to be read in a LOOP loop can also be limited using optional conditions. If no conditions are declared, all table rows are read.

Within the loop, the key being used can be addressed using the predefined loop_key. This is possiblein all statements where the table key keynameis used and where it can be declared explicitly. This type of statement must then be executed in the loop itself. Including the statement in a procedure that is called in the loop is not sufficient.

Addition 1

... USING KEY keyname

Effect

Using the USING KEY addition, a table key can be specified in keynamewith which processing is carried out. The specified table key influences the sequence in which the table rows are accessed, and the evaluation of the remaining conditions.

If the primary table key is specified, processing behaves in the same way as when no key is explicitly specified. If asecondary table key is specified, the sequence 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
  
  
• Specification of a hash key
  The rows are processed in the sequence in which they were inserted into the table.
  

Note

In contrast to processing a hash table when a primary key is used, a preceding sort using the SORT statement has no influence on the processing sequence when a secondary hash key is specified.

Example

See Loop though internal table with key specification.

Addition 2

... [FROM idx1] [TO idx2]

Effect

These additions have the effect that only table rows from row number idx1, or up to row numberidx2, are taken into account in the table index used. If only FROM is specified, all rowsof the table from row number idx1 up to and including the last row are taken into account. Ifonly TO is specified, all rows in the table from the first row up to row number idx2 are taken into account.

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

If a sortedsecondarykey is specified in keyname after USING KEY, the additions FROM and TO can be used for all table types and refer to the row numbers of thesecondary table index.

idx1 and idx2 are numerical expression positions of operand type i. The following limitations apply:

• If the value of idx1 is less than 0, it is set to 1 in the LOOP statement and causes aruntime error in every other statement. 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 0, the LOOP statement is not carried out and in everyother statement it leads to a runtime error. 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 duringloop processing are not taken into account. In contrast, the value of idx2 is evaluated in each loop pass and any changes made to idx2 during loop processing are taken into account.

Note

To determine when loop processing is exited and whether the value specified in idx2 has beenreached, the current line number is evaluated. Note that this number can be changed if lines are insertedor deleted during a loop pass as described in LOOP.As a result, there may be more loop passes (if lines are inserted) or fewer loop passes (if lines 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. You can declare WHERE for all table categories.

After WHERE, you can declare a logical expression log_exp in which the first operand of each operation is acomponent of the internal table. You cannot specify apredicatefunction. The components of the internal table must be declared as individual operands and not aspart of an expression. You cannot use parenthesized character-type data objects to declare a component dynamically here. The remaining operands of an operation can be anysuitable individual operands orcalculationexpressions, but not components of the internal table. All logical expressions are possible exceptfor the IS ASSIGNED,IS SUPPLIED,and obsolete IS REQUESTED predicates. The specified components can be of any data type. For evaluations, the relevantcomparison rules apply.

When standardtables are accessed without a secondary key being specified, access is not optimized since all rows of the internal table are checked for the logical expression of the WHERE addition.

When a sorted key or ahash key is used, that is, when asorted table, ahashed table, or asecondary table key is accessed, access is optimized in the following circumstances:

• If a sortedkey is declared, the logical expression uses comparisons linked with AND with the relationaloperator = (or EQ) to include an initial part of the key that consists of at least one component. An AND operation with further comparisons is possible.
  
• If a hashkey is declared, the logical condition uses comparisons linked with AND with the relationaloperator = (or EQ) to include all components of the key. An AND operation with further comparisons is possible
  
• The logical expression selects the same rows as a READ TABLE statement, in which the relevant components are specified as keys.
  

If the prerequisites for accessing a sorted or hashed table by means of the primary key are not met, optimization is not achieved and all rows of an internal table are checked as with standard tables.

,,When a secondary table key is accessed, that is, if one is specified in keyname after USING KEY,optimized execution is ensured, provided that the prerequisites above are met. Otherwise, a syntax error or exception occurs.

Notes

• When using a WHERE condition, note that thecomparison rulesfor incompatible data types apply when incompatible data objects are compared, whereby the data typesinvolved determine which operand is converted. In contrast, when the WITHTABLE KEY and WITHKEY additions of the READ statements are used, the content of the specified data objectsis always converted into the data type of the columns before the comparison is made, which can lead to different results.
  
• When access is optimized, the WHERE condition is mapped internally to a READstatement with specification of the relevant key.
  
• Since the WHERE condition can only optimized if it produces the same results as a READ statement with the corresponding key specification, all operands of the logical expression should becompatiblein pairs, if possible. This ensures that the result is not affected by the different behavior of the WHERE condition and the READ statement with a key specification.
  
• If a selectiontable is specified after INas a logical expression, note that the expression for the initial table is always true and all rows are then processed.
  
  
• 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.
  
  
  

Example

The following example demonstrates the differences in behavior of a WHERE condition and a key access with WITH TABLE KEY. With LOOP AT itab WHERE, the rule for thecomparison ofcharacter-like data types applies. The short column content "AA" is first filled with spaces tochange the length to 4. It is then compared to "AAXX". No matching row is found. With READ TABLE itab WITH TABLE KEY, the content of text_long isconvertedto the value "AA" before the comparison, by truncating two characters, and then compared to the column content. The result is output without errors.

DATA text_short TYPE c LENGTH 2.
DATA text_long  TYPE c LENGTH 4.

DATA itab LIKE TABLE OF text_short WITH NON-UNIQUE KEY table_line.

text_short = 'AA'.
text_long  = 'AAXX'.

APPEND text_short TO itab.

LOOP AT itab INTO text_short WHERE table_line = text_long.
ENDLOOP.
WRITE: / 'LOOP:', sy-subrc.

READ TABLE itab INTO text_short WITH TABLE KEY table_line = text_long.
WRITE: / 'READ:', sy-subrc.

Addition 4

... WHERE (cond_syntax)

Effect

Dynamic WHERE Condition cond_syntax can be specified as a character-like data object orstandardtable with character-like data type that, when the statement is executed, contains the syntax of a logical expression (in accordance with the rules of the static WHERE condition) or is initial.

The syntax in cond_syntax is, as in the ABAP Editor, not case-sensitive. When specifying an internaltable, you can distribute the syntax over multiple rows. If cond_syntax is initial when the statement is executed, the logical expression is true. Invalid logical expressions trigger an exception from the classCX_SY_ITAB_DYN_LOOP.

The obsolete relational operators (><, =>, and =<) are not supported in cond_syntax.

Notes

• Of the calculation expressions, onlyarithmetic expressions are currently supported.String expressions andbit expressions are not supported.String functions andbit functions cannot be specified either.
  
• The dynamic WHERE conditions is not evaluated for a blank table for optimization reasons. Therefore, if an internal table is blank, and a logical expression has errors, no exception is raised.
  
  
  

Example

Reading lines with particular line numbers in the primary table index that meet a condition. The static and dynamic declaration of a WHERE condition are shown.

DATA: BEGIN OF line,
         col1 TYPE i,
         col2 TYPE i,
      END OF line.

DATA itab LIKE SORTED TABLE OF line WITH UNIQUE KEY table_line.

DATA num TYPE i VALUE 400.
DATA dref TYPE REF TO i.
DATA cond TYPE string.

DO 30 TIMES.
  line-col1 = sy-index.
  line-col2 = sy-index ** 2.
  APPEND line TO itab.
ENDDO.

GET REFERENCE OF num INTO dref.

LOOP AT itab INTO line FROM 10 TO 25 WHERE col2 > dref->*.
  WRITE / line-col2.
ENDLOOP.

SKIP.

cond = 'col2 > dref->*'.

LOOP AT itab INTO line FROM 10 TO 25 WHERE (cond).
  WRITE / line-col2.
ENDLOOP.

General Material Data   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.


Length: 19271 Date: 20120523 Time: 000652     triton ( 474 ms )