Ansicht
Dokumentation

ABAPLOOP_AT_ITAB_COND - LOOP AT ITAB COND

ABAPLOOP_AT_ITAB_COND - LOOP AT ITAB COND

rdisp/max_wprun_time - Maximum work process run time   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

LOOP AT itab, cond

Kurzreferenz



... $[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.
  • 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.

LOOP mit Schrittgröße

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

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 )