Ansicht
Dokumentation
ABAPLOOP_AT_ITAB_COND - LOOP AT ITAB COND
rdisp/max_wprun_time - Maximum work process run time BAL Application Log DocumentationDiese Dokumentation steht unter dem Copyright der SAP AG.
LOOP AT itab, cond
... $[USING KEY keyname$]
$[FROM idx1$] $[TO idx2$] $[STEP n$]
$[WHERE log_exp$|(cond_syntax)$] ...
Zusätze:
1. ... USING KEY keyname
2. ... $[FROM idx1$] $[TO idx2$]
3. ... STEP n
4. ... WHERE log_exp
5. ... WHERE (cond_syntax)
Wirkung
Mit diesen optionalen Zusätzen zu LOOP AT itab wird eine Untermenge zu verarbeitender Zeilen und die Ausführungsreihenfolge der Schleife angegeben.
- Die Untermenge der Zeilen kann wie folgt definiert werden:
- Mit FROM und TO, mit denen ein Intervall von Zeilennummern für Indextabellen definiert wird
- Mit WHERE, mit dem Zeilen selektiert werden, die eine in einem logischen Ausdruck angegebene Bedingung erfüllen
- Mit STEP, mit dem durch die Definition einer Schrittgröße größer 1 Zeilen übersprungen werden dürfen.
- Die Verarbeitungsreihenfolge kann wie folgt definiert werden:
- Mit USING KEY keyname, mit dem der für die Schleife verwendete Tabellenschlüssel definiert und daher auch die durch die Tabellenart ermittelte Standardreihenfolge übersteuert wird.
- Mit STEP, mit dem durch die Angabe einer negativen Schrittgröße eine umgekehrte Reihenfolge definiert wird.
Falls keine der Bedingungen angegeben werden, werden alle Tabellenzeilen in der durch die Tabellenart
wie unter LOOP AT itab beschriebenen Standardreihenfolge gelesen.
Zusatz 1
... USING KEY keyname
Wirkung
Mit dem optionalen Zusatz USING KEY wird ein Tabellenschlüssel keyname angegeben, mit dem die Verarbeitung ausgeführt wird. Der angegebene Tabellenschlüssel beeinflusst die Reihenfolge, in der auf die Tabellenzeilen zugegriffen wird, und die Auswertung der anderen Bedingungen.
Falls der primäre Tabellenschlüssel über seinen Namen primary_key angegeben ist, verhält sich die Verarbeitung wie ohne explizite Schlüsselangabe. Falls ein sekundärer Tabellenschlüssel angegeben ist, ist die Reihenfolge, in der auf die Zeilen zugegriffen wird, wie folgt: STEP.
- Die Zeilen werden nach aufsteigenden Zeilennummern im sekundären Tabellenindex verarbeitet. Das Systemfeld sy-tabix enthält in jedem Schleifendurchlauf die Zeilennummer der aktuellen Zeile im zugehörigen sekundären Tabellenindex.
- Die Zeilen werden in der Reihenfolge verarbeitet, in der sie in die Tabelle eingefügt wurden. Das Systemfeld sy-tabix enthält in jedem Schleifendurchlauf den Wert 0. Eine vorhergehende Sortierung mit der Anweisung SORT ändert diese Verarbeitungsreihenfolge nicht.
Die mit USING KEY definierte Reihenfolge kann mit dem Zusatz STEP und einer negativen Schrittgröße umgekehrt werden.
Innerhalb der Schleife kann der verwendete Schlüssel über den vordefinierten Namen loop_key angesprochen werden. Dies ist in allen Anweisungen möglich, in denen explizit der zu verwendende Tabellenschlüssel keyname angegeben werden kann. Eine solche Anweisung muss dann in der Schleife selbst aufgeführt sein. Es genügt nicht, dass sie in einer Prozedur steht, die in der Schleife aufgerufen wird.
Hinweise
- Dass die über einen sekundären Hash-Schlüssel definierte Verarbeitungsreihenfolge von einer vorübergehenden SORT-Anweisung nicht betroffen ist, stellt ein anderes Verhalten dar als die über den primären Schlüssel einer Hash-Tabelle definierte Verarbeitungsreihenfolge, die doch von einer vorhergehenden Sortierung betroffen ist.
- Bei der Angabe eines sekundären Tabellenschlüssels muss eine gleichzeitig angegebene WHERE-Bedingung optimierbar sein, sonst kommt es zu einem Syntaxfehler oder einer Ausnahme.
Beispiel
Das Beispiel demonstriert den Unterschied von Schleifen ohne und mit Angabe eines sortierten sekundären
Tabellenschlüssels über eine Standardtabelle von Zufallszahlen. Die erste Schleife gibt
die Zeilen in der Reihenfolge zurück, in der sie angehängt wurden. Die zweite Schleife gibt die Zeilen aufsteigend sortiert zurück.
Schleife über interne Tabelle mit Schlüsselangabe
Zusatz 2
... $[FROM idx1$] $[TO idx2$]
Wirkung
Diese Zusätze bewirken, dass nur Tabellenzeilen ab der Zeilennummer idx1 bzw. bis einschließlich zur Zeilennummer idx2 im verwendeten Tabellenindex berücksichtigt werden. Wenn nur FROM angegeben ist, werden alle Zeilen der Tabelle ab Zeilennummer idx1 bis einschließlich der letzten Zeile berücksichtigt. Wenn nur TO angegeben ist, werden alle Zeilen der Tabelle ab der ersten Zeile bis zur Zeilennummer idx2 berücksichtigt.
Wenn der Zusatz USING KEY nicht verwendet wird oder in keyname der primäre Tabellenschlüssel angegeben ist, sind die Zusätze FROM und TO nur bei Indextabellen möglich und beziehen sich auf die Zeilennummern des primären Tabellenindex.
Wenn in keyname hinter USING KEY ein sortierter Sekundärschlüssel angegeben ist, sind die Zusätze FROM und TO bei allen Tabellenarten möglich und beziehen sich auf die Zeilennummern des zugehörigen sekundären Tabellenindex.
idx1 und idx2 sind numerische Ausdruckspositionen vom Operandentyp i. Dabei gelten folgende Einschränkungen:
-
Falls der Wert von idx1 kleiner gleich 0 ist, wird er in der Anweisung LOOP auf 1 gesetzt
und führt in jeder anderen Anweisung zu einem Laufzeitfehler. Falls der Wert von idx1 größer als die Anzahl der Tabellenzeilen ist, wird keine Verarbeitung ausgeführt.
-
Falls der Wert von idx2 kleiner gleich 0 ist, wird die Anweisung LOOP nicht ausgeführt
und es kommt in jeder anderen Anweisung zu einem Laufzeitfehler. Falls der Wert von idx2 größer als die Anzahl der Tabellenzeilen ist, wird er auf die Anzahl der Tabellenzeilen gesetzt.
-
Falls der Wert von idx2 kleiner dem Wert von idx1 ist, wird keine Verarbeitung ausgeführt.
Der Wert von idx1 wird einmalig beim Eintritt in die Schleife ausgewertet. Eventuelle Änderungen von idx1 während der Schleifenverarbeitung werden nicht berücksichtigt. Der Wert von idx2 wird dagegen bei jedem Schleifendurchgang ausgewertet und eventuelle Änderungen von idx2 während der Schleifenverarbeitung werden berücksichtigt.
Die Zusätze FROM und TO können zusammen mit STEP angegeben werden und es gelten dann spezielle Regeln.
Hinweis
Zur Bestimmung wann die Schleifenverarbeitung verlassen wird bzw. ob der in idx2 angegebene Wert
erreicht wurde wird die aktuelle Zeilennummer ausgewertet. Dabei ist zu beachten, dass diese Zahl durch
das Einfügen oder Löschen von Zeilen während eines Schleifendurchgangs wie unter
LOOP beschrieben umgesetzt werden
kann. Es kann vorkommen, dass die Schleife beim Einfügen von Zeilen weniger oft und beim Löschen
von Zeilen öfter durchlaufen wird, als es durch die Differenz aus idx2 und idx1 vorgegeben ist.
Beispiel
Feststellen des Primärindex einer bestimmten Tabellenzeile über die eingebaute Funktion
line_index und Schleife über die interne Tabelle ab dieser Zeile.
Zusatz 3
... STEP n
Wirkung
Mit dem optionalen Zusatz STEP n wird die Schrittgröße und Richtung der Schleife definiert. Die Schrittgröße wird durch den absoluten Wert von n und die Richtung durch das positive oder negative Vorzeichen von n definiert. n ist eine numerische Ausdrucksposition vom Operandentyp i. Falls der Zusatz STEP angegeben wird, ist die Schrittgröße 1 und es wird die Schleifenreihenfolge nur durch die Tabellenart oder den Zusatz USING KEY definiert.
Die Zusatzschrittgröße darf mit den Zusätzen FROM, TO und WHERE kombiniert werden und wirkt dann auf die Untermenge von durch diese Bedingungen definierten Tabellenzeilen. Für solche Kombinationen gelten folgende spezielle Regeln:
- FROM idx1 oder TO idx2 wird mit STEP kombiniert:
- Beim Wert von n größer 0, muss idx1 kleiner gleich idx2 sein.
- Beim Wert von n kleiner 0, muss idx1 größer gleich idx2 sein.
- Wenn keine dieser Einschränkungen erfüllt sind, wird die Schleife als leer interpretiert. Alle anderen Einstellungen für FROM idx1 und TO idx2 werden wie bei ... $[FROM idx1$] $[TO idx2$] beschrieben.
- Bei der Kombination einer WHERE-Bedingung mit STEP, darf das Argument n nur den Wert 1 oder -1 haben. Andere Werte führen zu einem Syntaxfehler oder zum unbehandelbaren Laufzeitfehler ITAB_ILLEGAL_STEP_SIZE. Die Bedingung WHERE muss hinter STEP n stehen.
Die detaillierte Wirkung des Zusatzes STEP ist wie folgt:
- Schrittgröße
- Mit dem absoluten Wert von n wird die Schrittgröße der Schleife über alle Tabellenzeilen oder über die durch die Bedingungen FROM, TO und WHERE definierte Untermenge von Tabellenzeilen angegeben. Beginnend bei der ersten Zeile der Tabelle oder Untermenge für die Vorwärtsreihenfolge oder bei der letzten Zeile der Untermenge für die Rückwärtsreihenfolge,
- falls der absolute Wert von n gleich 1 ist, wird jede Zeile gelesen,
- falls der absolute Wert von n gleich 2 ist, wird jede zweite Zeile gelesen,
- usw.
- Falls der absolute Wert von n größer als die in der Untermenge verfügbaren Zeilen ist, wird nur die erste oder letzte Zeile der Untermenge verarbeitet.
- Schleifenreihenfolge
- Mit dem Vorzeichen von n wird die durch die Tabellenart oder den Zusatz USING KEY definierte Schleifenreihenfolge erhalten oder umgekehrt:
- Falls der Wert von n größer 0 ist, wird die Schleifenreihenfolge nicht geändert. Es wird eine Vorwärtsschleife durchlaufen, die mit der ersten Tabellenzeile oder der ersten Zeile der Untermenge beginnt.
- Falls der Wert von n kleiner 0 ist, wird die Schleifenreihenfolge umgekehrt. Es wird eine Rückwärtsschleife durchlaufen, die mit der letzten Tabellenzeile oder der letzten Zeile der Untermenge beginnt.
- Mit der Angabe einer umgekehrten Schleifenreihenfolge wird die Standardreihenfolge wie folgt geändert:
- Mit einer umgekehrten Schleifenreihenfolge ohne Angabe eines sekundären Schlüssels hinter USING KEY wird die durch die Tabellenart definierte Schleifenreihenfolge umgekehrt. Für Indextabellen wird der primäre Tabellenindex beginnend mit dem höchsten Indexeintrag in absteigender Reihenfolge rückwärts verarbeitet und es werden die entsprechenden Tabellenzeilen gelesen. Bei Hash-Tabellen werden die Tabellenzeilen in der umgekehrten Reihenfolge des Einfügens in die Tabelle rückwärts gelesen oder werden nach einer SORT-Anweisung sortiert.
- Mit einer umgekehrten Schleifenreihenfolge mit Angabe eines sekundären Schlüssels hinter USING KEY wird die durch den sekundären Schlüssel definierte Schleifenreihenfolge umgekehrt. Für einen sortierten sekundären Schlüssel wird der entsprechende sekundäre Index beginnend mit dem höchsten Indexeintrag in absteigender Reihenfolge rückwärts verarbeitet und es werden die entsprechenden Tabellenzeilen gelesen. Bei einem sekundären Hash-Schlüssel werden die Tabellenzeilen in der umgekehrten Reihenfolge des Einfügens in die Tabelle rückwärts gelesen (hier hat eine vorhergehende Sortierung mit SORT keine Wirkung).
Der Wert von n darf nicht 0 sein. Falls der Wert 0 für n statisch erkennbar ist, kommt es zu einem Syntaxfehler. Falls der Wert 0 nur zur Laufzeit erkennbar ist, bricht das Programm mit dem Laufzeitfehler ITAB_ILLEGAL_STEP_SIZE ab, der nicht behandelbar ist. Eine Änderung des Wertes n innerhalb der Schleife hat keine Wirkung auf die Schrittgröße oder die Schleifenreihenfolge.
Wie üblich enthält sy-tabix bei der Verwendung eines Tabellenindex die Zeilennummer der in einem Schleifendurchgang gelesenen aktuellen Zeile oder bei der Verwendung eines Hash-Schlüssels 0.
Hinweise
- Mit dem Zusatz STEP wird die eigentliche Sortierreihenfolge der Tabelle nicht geändert, wie sie durch die Tabellenart oder für einen sekundären Index definiert ist. Es wird die Verarbeitungsreihenfolge der aktuellen Schleife bezüglich dieser Sortierreihenfolge geändert.
- Die Kontrollstrukturen für Gruppenstufenverarbeitung AT FIRST, AT LAST, AT NEW und AT END OF sind von STEP nicht unterstützt.
- STEP n kann aber anders positioniert werden. Die Verwendung hinter FROM idx1 und TO idx2 ist empfohlen.
Beispiel
In folgendem Beispiel wird die Verwendung von STEP n als umgekehrte Schleife in Kombination mit FROM idx1 und TO idx2 gezeigt. Als Ergebnis werden Zeile 3, Zeile 2 und Zeile 1 wie im primären Tabellenindex definiert in der angegebenen Reihenfolge verarbeitet.
Ausnahmen
Unbehandelbare Ausnahmen
- Ursache: Ungültige Schrittgröße für die Anweisung.
Laufzeitfehler: ITAB_ILLEGAL_STEP_SIZE
- Ursache: Die Anweisung unterstützt nur integrale Datenobjekte.
Laufzeitfehler: OBJECTS_NOT_INTEGRAL
Zusatz 4
... WHERE log_exp
Wirkung
Statische WHERE-Bedingung. Es werden alle Zeilen verarbeitet, für welche die Bedingung hinter WHERE erfüllt ist. Die Angabe WHERE ist bei allen Tabellenarten möglich.
Hinter WHERE kann ein logischer Ausdruck log_exp angegeben werden, in dem als erster Operand jedes einzelnen Vergleichs eine Komponente der internen Tabelle angegeben ist. Eine Prädikatfunktion kann nicht angegeben werden. Die Komponenten der internen Tabelle müssen als einzelner Operand, d.h. nicht als Teil eines Ausdrucks, angegeben werden. Die dynamische Angabe einer Komponente über eingeklammerte zeichenartige Datenobjekte ist hier nicht möglich. Die übrigen Operanden eines Vergleichs können beliebige passende einzelne Operanden oder Rechenausdrücke aber keine Komponenten der internen Tabelle sein. Es sind alle logischen Ausdrücke bis auf die Prädikate IS ASSIGNED, IS SUPPLIED und dem obsoleten IS REQUESTED möglich. Die angegebenen Komponenten können einen beliebigen Datentyp haben. Für die Auswertung gelten die entsprechenden Vergleichsregeln.
Beim Zugriff auf Standardtabellen ohne Angabe eines Sekundärschlüssels ist der Zugriff nicht optimiert, d.h. es werden alle Zeilen der internen Tabelle auf den logischen Ausdruck des WHERE-Zusatzes überprüft.
Bei der Verwendung eines sortierten Schlüssels oder eines Hash-Schlüssels, d.h. beim Zugriff auf eine sortierte Tabelle, eine Hash-Tabelle oder über einen sekundären Tabellenschlüssel findet unter folgenden Umständen ein optimierter Zugriff statt:
-
Bei einem sortierten
Schlüssel deckt der logische Ausdruck ein aus mindestens einer Komponente bestehendes Anfangsstück
des Schlüssels über mit AND verknüpfte Vergleiche mit dem Vergleichsoperator = (oder EQ) ab. Eine AND-Verknüpfung mit weiteren Vergleichen ist möglich.
-
Bei einem Hash-Schlüssel
deckt der logische Ausdruck alle Komponenten des Schlüssels über mit AND verknüpfte
Vergleiche mit dem Vergleichsoperator = (oder EQ) ab. Eine AND-Verknüpfung mit weiteren Vergleichen ist möglich.
-
Der logische Ausdruck selektiert die gleichen Zeilen, wie eine Anweisung READ
TABLE, in der die entsprechenden Komponenten als Schlüssel angegeben werden.
Wenn diese Voraussetzungen bei einem Zugriff auf eine sortierte Tabelle oder eine Hash-Tabelle über den Primärschlüssel nicht gegeben sind, findet keine Optimierung statt und es werden wie bei einer Standardtabelle alle Zeilen der internen Tabelle überprüft.
Beim Zugriff über einen
sekundären Tabellenschlüssel, d.h., wenn in keyname hinter USING KEY
ein solcher angegeben ist, wird eine optimierte Ausführung garantiert, d.h., obige Voraussetzungen müssen erfüllt sein. Andernfalls kommt es zu einem Syntaxfehler bzw. einer Ausnahme.
Hinweise
-
Bei der Verwendung einer WHERE-Bedingung ist zu beachten, dass beim Vergleich inkompatibler Datenobjekte die
Vergleichsregeln für inkompatible
Datentypen gelten, bei denen es von den beteiligten Datentypen abhängt, welcher Operand konvertiert
wird. Bei Verwendung der Zusätze WITH
TABLE KEY und WITH KEY
der Anweisung READ wird dagegen immer der Inhalt der angegebenen Datenobjekte vor dem Vergleich in den Datentyp der Spalten konvertiert, wodurch es zu unterschiedlichen Ergebnissen kommen kann.
-
Beim optimierten Zugriff wird die WHERE-Bedingung intern auf eine READ-Anweisung mit entsprechender Schlüsselangabe abgebildet.
-
Da eine Optimierung der WHERE-Bedingung nur stattfinden kann, wenn diese die gleichen Ergebnisse
hat, wie eine READ-Anweisung mit entsprechender Schlüsselangabe, sollten alle Operanden des logischen Ausdrucks möglichst paarweise
kompatibel sein.
Damit ist sichergestellt, dass das unterschiedliche Verhalten der WHERE-Bedingung und einer Schlüsselangabe bei der Anweisung READ keinen Einfluss auf das Ergebnis hat.
-
Wenn als logischer Ausdruck eine Selektionstabelle
hinter IN angegeben ist,
ist zu beachten, dass der Ausdruck bei einer initialen Selektionstabelle immer wahr ist und dass dann alle Tabellenzeilen verarbeitet werden.
- Der hinter WHERE angegebene logische Ausdruck wird einmalig beim Eintritt in die Schleife
ausgewertet. Eventuelle Änderungen des zweiten Operanden während der Schleifenverarbeitung werden nicht berücksichtigt.
Beispiel
Das folgende Beispiel demonstriert das unterschiedliche Verhalten einer WHERE-Bedingung im Vergleich zu einem Schlüsselzugriff mit WITH TABLE KEY. In LOOP AT itab WHERE gilt die Regel für den
Vergleich von zeichenartigen Datentypen.
Der kurze Spalteninhalt "AA" wird erst
mit Leerzeichen aufgefüllt, um die Länge auf 4 zu erweitern, und dann mit
"AAXX" verglichen. Es wird keine übereinstimmende Zeile gefunden. Bei READ TABLE itab
WITH TABLE KEY wird der Inhalt von text_long dagegen vor dem Vergleich durch das Abschneiden von zwei Zeichen in den Wert "AA"
konvertiert und dann mit dem Spalteninhalt verglichen. Dadurch ist das Auslesen erfolgreich.
Zusatz 5
... WHERE (cond_syntax)
Wirkung
Dynamische WHERE-Bedingung. Für cond_syntax kann ein zeichenartiges Datenobjekt oder eine Standardtabelle mit zeichenartigem Datentyp angegeben werden, das bei Ausführung der Anweisung die Syntax eines logischen Ausdrucks nach den Regeln der statischen WHERE-Bedingung enthält oder initial ist.
Die Syntax in cond_syntax ist wie im ABAP Editor unabhängig von Groß- und Kleinschreibung . Bei der Angabe einer internen Tabelle kann die Syntax auf mehrere Zeilen verteilt sein. Wenn cond_syntax bei Ausführung der Anweisung initial ist, ist der logische Ausdruck wahr. Ein ungültiger logischer Ausdruck führt zu einer Ausnahme der Klasse CX_SY_ITAB_DYN_LOOP.
Die obsoleten Vergleichsoperatoren (><, => und =<) werden in cond_syntax nicht unterstützt.
Hinweise
-
Von den Rechenausdrücken werden derzeit nur
arithmetische Ausdrücke aber keine
Zeichenkettenausdrücke und keine
Bit-Ausdrücke unterstützt. Ebenso können noch keine
Zeichenkettenfunktionen oder
Bit-Funktionen angegeben werden.
-
Die dynamische WHERE-Bedingung wird aus Optimierungsgründen für eine leere Tabelle
nicht ausgewertet. Bei einer leeren internen Tabelle kommt es bei einem fehlerhaften logischen Ausdruck damit nicht zu einer Ausnahme.
Beispiel
Auslesen von Zeilen mit bestimmten Zeilennummern im primären Tabellenindex, die eine Bedingung erfüllen. Es werden die statische und die dynamische Angabe einer WHERE-Bedingung gezeigt.
Addresses (Business Address Services) Vendor Master (General Section)
Diese Dokumentation steht unter dem Copyright der SAP AG.
Length: 31770 Date: 20240424 Time: 015101 sap01-206 ( 448 ms )