LOOP - Loop on an internal table

Basic form

LOOP AT itab.

LOOP AT itab INTO wa.

LOOP AT itab ASSIGNING <fs>.

LOOP AT itab REFERENCE INTO dref.

Extras:

1. ... FROM n1

2. ... TO n2

3. ... TRANSPORTING NO FIELDS

4. ... WHERE logexp

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Short Forms in Line Operations and Cannot Change an Internal Table in a Loop.

Effect

Processes an internal table (DATA) in a loop which begins with LOOP and ends with ENDLOOP. Each of the internal table entries is sent to the output area in turn.

When you use LOOP AT itab, the header line of the internal table itab is used as the output area (this is only possible for tables with a header line). When you use LOOP AT itab INTO wa, the explicitly specified work area wa is used as the output area. In both cases, the current table line is copied into the output area.
To avoid the costs for the copy process, you can use the additions ASSIGNING <fs> and REFERENCE INTO dref. In both cases, the system directly processes the contents of the internal table. If you use the ASSIGNING addition, the field symbol <fs> points to the respective current line. If you use REFERENCE INTO dref, the reference of the current line is put into dref. Within the loop, neither the field symbol <fs> nor the reference dref must be processed.
If the table is empty, or if the additions prevent the system from choosing an entry, the output area (field symbol or the reference variable) remains unchanged. At the end of the loop, the output area displays (or the field symbol or the reference points to) the last entry selected.


If the internal table is empty, all the statements between LOOP and ENDLOOP are ignored.

The sequence in which the entries occur in the loop depend on the table type specified in the table definition (unless the table has been explicitly resorted using the SORT statement:

STANDARD TABLE:
The system processes entries according to their logical index. At the beginning of a loop pass, SY-TABIX is set to the logical index of the current table entry.


SORTED TABLE:
The system processes entries according to their sort order. As with standard tables, the system sets SY-TABIX to the logical index of the current table entry.


HASHED TABLE:
The system processes entries in the order in which they were inserted into the table. Since hashed tables have no logical index, SY-TABIX is always set to 0.


When the system exits a LOOP, the index field SY-TABIX always has the same value it had before the loop was processed.

Inserting and/or deleting lines in a LOOP affects subsequent loop passes.

For control break processing in a LOOP on internal tables, there are special control break control structures for internal tables you can use.

You can use the CONTINUE statement to leave the current loop pass prematurely and continue with the next loop pass. To leave loop processing altogether, you use EXIT.

At the end of loop processing (that is after ENDLOOP), the return code value of SY-SUBRC specifies whether the loop was actually processed.

SY-SUBRC = 0:
The loop was executed at least once.
SY-SUBRC = 4:
The loop was not executed, either because there was no entry at all or because there was no entry which satisfied the conditions.

The statement LOOP AT also fills the system fields SY-TFILL and SY-TLENG.

Example

The table itab is defined as follows:

DATA: BEGIN OF STRUC,
        NAME(10) TYPE C,
        BLNCE    TYPE P,
      END OF STRUC,
      ITAB LIKE TABLE OF STRUC.

After the table has been filled with data (using APPEND), it is then output:

LOOP AT ITAB INTO STRUC.
  WRITE: / STRUC-NAME, STRUC-SALDO.
ENDLOOP.

Notes

  1. If you use the ASSIGNING <fs> addition, you are working directly on the internal table entries. However, you must not manipulate the key components of a table of the SORTED or HASHED TABLE - otherwise, the table may not be sorted correctly. This would then mean that any modifying operation (such as MODIFY, MOVE, CLEAR) or potentially modifying operation (such as passing an entry as a CHANGING parameter) would cause a runtime error.

You cannot change a complete internal table by using a loop on it. To change a complete table, use the REFRESH, CLEAR, FREE, MOVE, SORT, or SELECT ... INTO/APPENDING statements. This rule also applies to passing a table as a CHANGING VALUE parameter.

  1. If you only intend to work on the table under certain conditions (if you have used a FROM, TO, or WHERE addition), you should not use Control breaks with internal tables , since the interplay between conditional LOOP and AT statements is not well- defined at present. (AT NEW and AT END OF cause the previous table line to be compared, not the selected line. A conditional LOOP may not be aware that a control break has occurred).

If you use SUM in the LOOP processing, and also explicitly declare an output area wa, this area must have the same line type as the internal table itab.

Addition 1

... FROM n1

Addition 2

... TO n2

Effect

Places all internal table entries from the entry with the index (SY-TABIX) = n1 to the entry with the index = n2 inclusive in the output area in turn.

You cannot use these addtions for HASHED TABLEs, because hashed tables have no defined index operations.

Notes

If either one of the additions " FROM n1" or "TO n2 " is missing, then the table is processed either from the first entry or up to the last entry (according to what is missing).

  1. Note the special aspects you must consider when inserting and/or deleting lines in a LOOP loop.


Example

Output table entries 7 and 8:

LOOP AT ITAB INTO STRUC FROM 7 TO 8.
   WRITE: / STRUC-NAME, STRUC-BLNCE.
ENDLOOP.

Addition 3

... TRANSPORTING NO FIELDS

Effect

There is no field transport in the output area of the internal table. This addition can be used only in conjunction with a WHERE condition. Since it would make no sense to specify a work area with INTO wa when using the addition TRANSPORTING NO FIELDS, this option does not exist.
This addition can be used to determine a set of line indexes (index set) or to determine the number of lines in a table which satisfy a given condition.

Example

Determining the number COUNT of lines in a name table TAB which contain the name 'Walter' and the corresponding index set INDEX_SET.

TYPES: BEGIN OF NAMETAB_TYPE,
         NAME(30) TYPE C,
       END OF NAMETAB_TYPE.

DATA:  NAMETAB TYPE STANDARD TABLE OF NAMETAB_TYPE WITH
               NON-UNIQUE DEFAULT KEY INITIAL SIZE 100,
       COUNT TYPE I,
       INDEX_SET TYPE STANDARD TABLE OF SY-TABIX WITH
               NON-UNIQUE DEFAULT KEY INITIAL SIZE 10,
       WA_INDEX_SET TYPE SY-TABIX.

LOOP AT NAMETAB TRANSPORTING NO FIELDS WHERE NAME CS 'Walter'.
   WA_INDEX_SET = SY-TABIX.
   APPEND WA_INDEX_SET TO INDEX_SET.
   ADD 1 TO COUNT.
ENDLOOP.

Addition 4

... WHERE logexp

Effect

Places all internal table entries which satisfy the condition logexp in turn in the output area. The condition logexp can be almost any logical expression. The only restriction is that the first field for each comparison must be a sub-field of the line structure of the internal table itab.

Example

LOOP AT ITAB INTO STRUC WHERE BLNCE <> 0.
     WRITE: STRUC-NAME, STRUC-BLNCE.
ENDLOOP.


which has the same effect as:

LOOP AT ITAB INTO STRUC.
  CHECK STRUC-BLNCE <> 0.
  WRITE: / STRUC-NAME, STRUC-BLNCE.
ENDLOOP.

You can replace any operand - unless it is a subfield of the line structure of the relevant internal table itab - with a functional method call. Function al methods are methods in ABAP Objects that can have any number of IMPORTING parameters and a RETURNING parameter.

Depending on the number of IMPORTING parameters, the following syntax options are available:

Example

CLASS c1 DEFINITION.
  PUBLIC SECTION.
  METHODS M1 IMPORTING NAME TYPE S_CARRNAME
             RETURNING VALUE(CARR) TYPE S_CARR_ID.
ENDCLASS.

CLASS c1 IMPLEMENTATION.
  METHOD M1.
    SELECT CARRID UP TO 1 ROWS
      FROM SCARR
      INTO CARR
     WHERE CARRNAME = NAME.
    ENDSELECT.
  ENDMETHOD.
ENDCLASS.

DATA: JTAB TYPE STANDARD TABLE OF SPFLI,
      LINE TYPE SPFLI.

DATA: OREF TYPE REF TO C1.

START-OF-SELECTION.

  SELECT * FROM SPFLI INTO TABLE JTAB.

  CREATE OBJECT oref TYPE c1.

  LOOP AT JTAB INTO LINE
               WHERE CARRID = OREF-> M1( 'Lufthansa' ).
    WRITE: / LINE-CARRID, LINE-CONNID,
             LINE-CITYFROM, LINE-CITYTO.
  ENDLOOP.

The actual parameters are passed to the IMPORTING parameters of the method as described in the CALL METHOD statement.

If the line type of the internal table is - or contains - a reference variable, the attributes of the object (to which the reference points in a given line) can be used as the first field in a comparison.

Example

see Using Object Attributes as Internal Table Keys

You cannot address parts of a field in a table without a structured line type (for example, tables of type I). However, you can use the TABLE_LINE notation to address the entire line within a WHERE condition (see also The Pseudo-Component TABLE_LINE in Internal Tables).

Example

The WHERE condition applied to a type I table

DATA: inttab TYPE STANDARD TABLE OF i WITH NON-UNIQUE
                  DEFAULT KEY,
      wa_inttab TYPE I.

LOOP AT inttab INTO wa_inttab WHERE table_line >   5 AND
                                    table_line <= 10.
  ...
ENDLOOP.

Notes

  1. When you use the WHERE condition with a STANDARD or HASHED table, a full table scan is always required.

    If you are working with a SORTED TABLE, the partial sequential processing can be optimized so that only the entries that actually satisfy the WHERE condition are processed. This optimization requires that each sub-condition is linked with AND; that no parentheses are used; that at least one sub-condition is in the form k = v; and that the conditions in the form k1 = v1 ... kn = vn cover at least the first part of the table key.

    The starting point for the loop is specified using a binary search with the sub-conditions that cover the table key (partially or completely). This optimization is similar to the optimization in the READ statement. The loop is only processed from the starting point to the point where these sub-conditions are still met. (See also Optimized Key Operations in Internal Tables).


  2. Each operand that appears in the logical expression of the WHERE condition is only evaluated once, at the start of the loop. Changes to its value that are made while the loop is running have no effect on the evaluation performed by the WHERE condition.


  3. ... WHERE logexp is a logical expression in the ABAP sense. It is a logical expression similar to IF, WHILE, or CHECK, not a WHERE clause in the SQL sense (like SELECT/UPDATE/DELETE ... WHERE).


  4. The interplay of the LOOP AT ... WHERE statement and ATcontrol breaks statements is undefined at present. You should therefore avoid using a LOOP with a WHERE condition in conjunction with the AT NEW/END OF or FIRST/LAST statements.


  5. Performance when processing a LOOP AT ... WHERE statement improves considerably if the fields compared are of the same type. For best results, define your comparison fields as follows:

    DATA comparison field LIKE table field.

    Example:

    DATA: CMP_NAME LIKE STRUC-NAME.

    CMP_NAME = 'Harold'.
    LOOP AT ITAB INTO STRUC WHERE NAME = CMP_NAME.
    WRITE: / STRUC-NAME, STRUC-SALDO.
    ENDLOOP.


Exceptions

Non-Catchable Exceptions

Related

Loop Structures:
DO, WHILE

Table Processing:
APPEND, COLLECT, INSERT, MODIFY, DELETE, SORT, AT NEW/END OF/FIRST/LAST, READ TABLE.

Additional help

Processing Lines of Tablesin Loops

Index Entries in Loops