Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Processing Internal Data →  Internal Tables →  Processing Statements for Internal Tables →  LOOP AT itab 

LOOP AT itab - Basic Form

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


LOOP AT itab result [cond]. 

  ... 
  [AT ... 

    ... 
  ENDAT.] 

  ... 
ENDLOOP.

Effect

This variant of the statement LOOP AT itab executes the statement block between LOOP and ENDLOOP once for each read row.

  • The output response result determines how and to where the row contents are read.
  • The table key with which the loop is executed can be determined in cond. Either all the rows are read or cond conditions are specified to restrict which rows are read.
  • AT ... ENDAT can be used to define control structures for control level processing.

If the internal table is specified as the return value or result of a functional method, a constructor expression, or a table expression, the value is persisted for the duration of the loop. Afterwards, it is no longer possible to access the internal table.

If no explicit table key name is specified after USING KEY, the order in which the rows are read depends on the table category as follows:

  • Standard tables and sorted tables
    The rows are read by ascending row numbers in the primary table index. In each loop pass, the system field sy-tabix contains the row number of the current row in the primary table index.
  • Hashed tables
    The rows are processed in the order in which they were inserted in the table, and by the sort order used after the statement SORT. In each loop pass, the system field sy-tabix contains the value 0.

The loop continues to run until all the table rows that meet the cond condition have been read or until it is exited with a statement. If no appropriate lines are found or if the internal table is blank, the loop is not run at all.

System Fields

This variant of the statement LOOP AT sets the value of the system field sy-tabix:

LOOP AT does not modify sy-subrc. After leaving the loop using ENDLOOP, sy-tabix is set to the value that it had before entering the loop and that applies for sy-subrc:

sy-subrc Meaning
0 (means: The loop was run at least once.
4 The loop was not run at all.

The system fields sy-tfill and sy-tleng are also filled.

Changing internal tables in a loop

If rows are inserted or deleted in the statement block of a LOOP, this has the following effects: The position of inserted or deleted lines with regard to the current line is determined by the line numbers in the corresponding table index in the case of loops on index tables or if using a sorted key. In the case of loops on hashed tables and if using a hash key, the position depends on the insertion sequence.

  • If you insert lines after the current line, these new lines will be processed in the subsequent loop passes. An endless loop can result.
  • If you delete lines after the current line, the deleted lines will no longer be processed in the subsequent loop passes.
  • If you insert lines before the current line, the internal loop counter is increased by one with each inserted line. This affects sy-tabix, which is also increased (in the subsequent loop pass in the case of loops on index tables or when using a sorted key).
  • If you delete the current line or lines before the current line, the internal loop counter is decreased by one with each deleted line. In the case of loops on index tables or if using a sorted key, this affects sy-tabix in the subsequent loop pass, and sy-tabix is decreased accordingly.

The replacement of the entire table body in a LOOP using this table causes the loop to be exited at the next loop pass in accordance with the rules described above. This is particularly the case if new rows were added to the table afterwards. Since this usually leads to unpredictable program behavior, you cannot access the entire table body in change mode in a loop. If this is known statically, a syntax error occurs in classes and for LOOPS with secondary keys known statically. Otherwise, the syntax check simply returns a warning for compatibility reasons. However, at runtime, a runtime error occurs in most cases when replacing the entire table body with statements such as CLEAR, FREE, LOCAL, REFRESH, SORT, DELETE ... WHERE, and with all types of assignments to itab.

Programming Guideline

Loop Processing


Notes

  • If the internal table itab is specified using a reference variable, the loop is executed completely using the table referenced at entry. Any changes to the reference variable do not have an effect on the loop. The associated object cannot be deleted from the Garbage Collector until the loop has been completed. The same thing is true if the table is represented by a field symbol. After the implementation of the field symbol in the loop, iteration still takes place using the table linked to the field symbol when LOOP is entered.
  • There is no implicit selection of a suitable key or index. The used table key or table index is always specified uniquely. The syntax check issues a warning if there is a suitable secondary table key but this table key is not used. This warning should be removed through using the key. However, in exceptional cases, it can be bypassed using a pragma.
  • It is generally better to read multiple rows in a LOOP than making multiple individual row reads using the statement READ TABLE or table expressions.
  • There is no addition that can reverse the order of the read rows. This must done using an iteration with DO, WHILE, or FOR in which individual rows are read using READ TABLE or using table expressions. The loop conditions must then be programmed accordingly in the loop (see the executable example).
  • Due to compatibility reasons, when a table body is replaced, the only situation where a runtime does not occur in the loop is when a directly specified table is read without a specified secondary key and when a work area wa is specified for output response result.
  • Using a special variant LOOP AT mesh_path, a loop can be executed across the last node of a mesh path.
  • A further form of table iterations are possible using iteration expressions and FOR in certain constructor expressions.


Example

Loop across an internal table constructed using the value operator VALUE, where each row is assigned to a field symbol declared inline using FIELD-SYMBOL.

TYPES t_itab TYPE TABLE OF i WITH EMPTY KEY. 

LOOP AT VALUE t_itab( ( 1 ) ( 2 ) ( 3 ) ) ASSIGNING FIELD-SYMBOL(<fs>). 
  cl_demo_output=>write( |{ <fs> }| ). 
ENDLOOP. 
cl_demo_output=>display( ).

Example

Nested LOOP loops without explicit key declaration. The contents of the current row for the outer loop are analyzed in the WHERE condition for the inner loop.

DATA name TYPE scarr-carrname VALUE '*'. 
cl_demo_input=>request( CHANGING field = name ). 

DATA: scarr_tab TYPE SORTED TABLE OF scarr 
                WITH UNIQUE KEY carrname, 
      spfli_tab TYPE SORTED TABLE OF spfli 
               WITH NON-UNIQUE KEY carrid. 

SELECT * 
       FROM scarr 
       INTO TABLE @scarr_tab. 

SELECT * 
       FROM spfli 
       INTO TABLE @spfli_tab. 

LOOP AT scarr_tab ASSIGNING FIELD-SYMBOL(<scarr_line>) 
                  WHERE carrname CP name. 
  LOOP AT spfli_tab INTO DATA(spfli_line) 
                   WHERE carrid = <scarr_line>-carrid. 
    cl_demo_output=>write_data( spfli_line ). 
  ENDLOOP. 
ENDLOOP. 
cl_demo_output=>display( ).

Exceptions

Handleable Exceptions

CX_SY_ITAB_DYN_LOOP

  • Cause: Error in a dynamic WHERE condition
    Runtime error: DYN_WHERE_PARSE_ERROR

Non-Handleable Exceptions

  • Cause: Illegal parsing of the LOOP field symbol in the body of the loop.
    Runtime error: ITAB_ILLEGAL_REG
  • Cause: Illegal assignment to the LOOP reference in the body of the loop.
    Runtime error: MOVE_TO_LOOP_REF
  • Cause: Invalid change of entire table body in the loop
    Runtime error: TABLE_FREE_IN_LOOP

Continue

LOOP AT itab - result

LOOP AT itab - cond

AT - Group Level Processing

Internal Tables, Loop with Key Specified