ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → LOOP AT itab
LOOP AT itab - Basic Form
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 orcond
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 fieldsy-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 statementSORT
. In each loop pass, the system fieldsy-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 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
:
- In each loop pass for index tables and when using a sorted key on the row number of the current table row in the associated table index.
-
In hashed tables and when using a
hash key on the value 0.
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 regard 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.
- If rows are inserted after the current row, these new rows are processed in the subsequent loop passes. An endless loop can result.
- If rows are deleted after the current row, the deleted rows are no longer processed in the subsequent loop passes.
-
If rows are inserted before the current row, the internal loop counter is increased by one with each
inserted row. 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 the current row or rows before the current row are deleted, the internal loop counter is decreased
by one with each deleted row. 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 produces unpredictable program
behavior, the entire table body cannot be accessed in change mode in a loop. If this is statically discernible,
a syntax error occurs in classes and for LOOPS
with statically discernible
secondary keys. 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
-
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 whenLOOP
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 statementREAD TABLE
or table expressions. -
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 responseresult
. -
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
s 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.
PARAMETERS p_name TYPE scarr-carrname DEFAULT '*'.
DATA: scarr_tab TYPE SORTED TABLE OF scarr
WITH UNIQUE KEY carrname,
spfli_tab TYPE SORTED TABLE OF spfli
WITH NON-UNIQUE KEY carrid.
FIELD-SYMBOLS <scarr_line> LIKE LINE OF scarr_tab.
DATA spfli_line LIKE LINE OF spfli_tab.
SELECT *
FROM scarr
INTO TABLE @scarr_tab.
SELECT *
FROM spfli
INTO TABLE @spfli_tab.
LOOP AT scarr_tab ASSIGNING <scarr_line>
WHERE carrname CP p_name.
LOOP AT spfli_tab INTO spfli_line
WHERE carrid = <scarr_line>-carrid.
cl_demo_output=>write_data( spfli_line ).
ENDLOOP.
ENDLOOP.
cl_demo_output=>display( ).
Exceptions
Catchable Exceptions
CX_SY_ITAB_DYN_LOOP
-
Cause: Error in a dynamic
WHERE
condition
Runtime Error:DYN_WHERE_PARSE_ERROR
Non-Catchable Exceptions
-
Cause: Illegal conversion of the
LOOP
field symbol in the core of the loop.
Runtime Error:ITAB_ILLEGAL_REG
-
Cause: Illegal assignment to the
LOOP
reference in the core 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