SAP NetWeaver AS ABAP Release 752, ©Copyright 2017 SAP AG. All rights reserved.
ABAP - Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → LOOP AT itab →
LOOP AT itab - Basic Form
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.
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:
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 rows 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 | 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 rows with respect to the current row is determined by the row 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 insert order.
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 produces unpredictable program
behavior, the entire table body cannot be accessed 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
Notes
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 LOOPs without an explicitly specified key. 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( ).
Handleable Exceptions
CX_SY_ITAB_DYN_LOOP
Non-Handleable Exceptions