ABAPLOOP_AT_ITAB_COND - LOOP AT ITAB COND

CPI1466 during Backup   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

LOOP AT itab - cond

Kurzreferenz

Syntax

... [USING KEY keyname] [FROM idx1] [TO idx2] [WHERElog_exp|(cond_syntax)] ... .

Zusätze:

1. ... USING KEY keyname

2. ... [FROM idx1] [TO idx2]

3. ... WHERE log_exp

4. ... WHERE (cond_syntax)

Wirkung

Mit USING KEY keynamewird der Tabellenschlüssel bestimmt, mit dem die Schleife ausgeführt wird. Weiterhin könnendie in einer LOOP-Schleife auszulesenden Tabellenzeilen durch optionale Bedingungen eingeschränkt werden; wenn keine Bedingungen angegeben sind, werden alle Zeilen der Tabelle gelesen.

Innerhalb der Schleife kann der verwendete Schlüssel über den vordefinierten Namen loop_keyangesprochen werden. Dies ist in allen Anweisungen möglich, in denen explizit der zu verwendendeTabellenschlüssel keynameangegeben 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.

Zusatz 1

... USING KEY keyname

Wirkung

Mit dem Zusatz USING KEY kann in keynameein Tabellenschlüssel angegeben werden, mit dem die Verarbeitung ausgeführt wird. Derangegebene Tabellenschlüssel beeinflusst die Reihenfolge, in der auf die Tabellenzeilen zugegriffen wird, und die Auswertung der übrigen Bedingungen.

Falls der primäre Tabellenschlüssel angegeben ist, verhält sich die Verarbeitung wie bei keiner expliziten Schlüsselangabe. Falls einsekundärerTabellenschlüssel angegeben ist, ist die Reihenfolge, in der auf die Zeilen zugegriffen wird, wie folgt:

• Angabe eines sortierten Schlüssels
  Die Zeilen werden nach aufsteigenden Zeilennummern imsekundären Tabellenindex verarbeitet.
  
  
• Angabe eines Hash-Schlüssels
  Die Zeilen werden in der Reihenfolge verarbeitet, in der sie in die Tabelle eingefügt wurden.
  

Hinweis

Im Unterschied zur Verarbeitung einer Hash-Tabelle unter Verwendung des Primärschlüssels,hat eine vorhergehende Sortierung mit der Anweisung SORT keinen Einfluss auf die Verarbeitungsreihenfolge wenn ein sekundärer Hash-Schlüssel angegeben ist.

Beispiel

Siehe 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ßlichzur Zeilennummer idx2 im verwendeten Tabellenindex berücksichtigt werden. Wenn nur FROMangegeben ist, werden alle Zeilen der Tabelle ab Zeilennummer idx1 bis einschließlichder 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 derprimäre Tabellenschlüssel angegeben ist, sind die Zusätze FROM und TO nur beiIndextabellen möglich und beziehen sich auf die Zeilennummern desprimären Tabellenindex.

Wenn in keyname hinter USING KEY einsortierterSekundärschlüsselangegeben ist, sind die Zusätze FROM und TO bei allen Tabellenarten möglich und beziehen sich auf die Zeilennummern des zugehörigensekundä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 gesetztund 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ührtund 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 Änderungenvon idx1 während der Schleifenverarbeitung werden nicht berücksichtigt. Der Wertvon idx2 wird dagegen bei jedem Schleifendurchgang ausgewertet und eventuelle Änderungen von idx2 während der Schleifenverarbeitung werden berücksichtigt.

Hinweis

Zur Bestimmung wann die Schleifenverarbeitung verlassen wird bzw. ob der in idx2 angegebene Werterreicht wurde wird die aktuelle Zeilennummer ausgewertet. Dabei ist zu beachten, dass diese Zahl durchdas Einfügen oder Löschen von Zeilen während eines Schleifendurchgangs wie unterLOOP beschriebenumgesetzt werden kann. Dadurch kann es vorkommen, dass die Schleife beim Einfügen von Zeilenweniger oft und beim Löschen von Zeilen öfter durchlaufen wird, als es durch die Differenz aus idx2 und idx1 vorgegeben ist.

Zusatz 3

... 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 eineKomponente der internen Tabelle angegeben ist. EinePrädikatfunktionkann 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 übereingeklammerte zeichenartige Datenobjekte ist hier nicht möglich. Die übrigen Operanden eines Vergleichs können beliebigepassende einzelne Operanden oderRechenausdrückeaber keine Komponenten der internen Tabelle sein. Es sind alle logischen Ausdrücke bis auf die Prädikate IS ASSIGNED, IS SUPPLIEDund dem obsoleten ISREQUESTED möglich. Die angegebenen Komponenten können einen beliebigen Datentyp haben. Für die Auswertung gelten die entsprechendenVergleichsregeln.

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 einesHash-Schlüssels, d.h. beim Zugriff auf einesortierte Tabelle, eineHash-Tabelle oder über einensekundärenTabellenschlüssel findet unter folgenden Umständen ein optimierter Zugriff statt:

• Bei einem sortiertenSchlüssel deckt der logische Ausdruck ein aus mindestens einer Komponente bestehendes Anfangsstückdes 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üsseldeckt der logische Ausdruck alle Komponenten des Schlüssels über mit AND verknüpfteVergleiche 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 READTABLE, in der die entsprechenden Komponenten als Schlüssel angegeben werden.
  

Wenn diese Voraussetzungen bei einem Zugriff auf eine sortierte Tabelle oder eine Hash-Tabelle überden 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 KEYein 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 dieVergleichsregelnfür inkompatible Datentypen gelten, bei denen es von den beteiligten Datentypen abhängt,welcher Operand konvertiert wird. Bei Verwendung der Zusätze WITHTABLE KEY und WITHKEY 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-Anweisungmit entsprechender Schlüsselangabe abgebildet.
  
• Da eine Optimierung der WHERE-Bedingung nur stattfinden kann, wenn diese die gleichen Ergebnissehat, wie eine READ-Anweisung mit entsprechender Schlüsselangabe, sollten alle Operanden des logischen Ausdrucks möglichst paarweisekompatibelsein. 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 INangegeben 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. Bei LOOP AT itab WHERE wirkt die Regel für denVergleich zeichenartigerDatentypen und der kürzere Spalteninhalt "AA" wird erst durch das Auffüllen mit Leerzeichenauf die Länge 4 gebracht und dann mit "AAXX" verglichen, wodurch keine passende Zeile gefundenwird. 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, wodurch das Auslesen erfolgreich ist.

DATA text_short TYPE c LENGTH 2.
DATA text_long  TYPE c LENGTH 4.

DATA itab LIKE TABLE OF text_short WITH NON-UNIQUE KEY table_line.

text_short = 'AA'.
text_long  = 'AAXX'.

APPEND text_short TO itab.

LOOP AT itab INTO text_short WHERE table_line = text_long.
ENDLOOP.
WRITE: / 'LOOP:', sy-subrc.

READ TABLE itab INTO text_short WITH TABLE KEY table_line = text_long.
WRITE: / 'READ:', sy-subrc.

Zusatz 4

... WHERE (cond_syntax)

Wirkung

Dynamische WHERE-Bedingung. Für cond_syntax kann ein zeichenartiges Datenobjekt oder eineStandardtabellemit 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_syntaxbei Ausführung der Anweisung initial ist, ist der logische Ausdruck wahr. Ein ungültiger logischer Ausdruck führt zu einer Ausnahme der KlasseCX_SY_ITAB_DYN_LOOP.

Die obsoleten Vergleichsoperatoren(><, => und =<) werden in cond_syntax nicht unterstützt.

Hinweise

• Von den Rechenausdrücken werden derzeit nurarithmetische Ausdrücke aber keineZeichenkettenausdrücke und keineBit-Ausdrücke unterstützt. Ebenso können noch keineZeichenkettenfunktionen oderBit-Funktionen angegeben werden.
  
• Die dynamische WHERE-Bedingung wird aus Optimierungsgründen für eine leere Tabellenicht 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.

DATA: BEGIN OF line,
         col1 TYPE i,
         col2 TYPE i,
      END OF line.

DATA itab LIKE SORTED TABLE OF line WITH UNIQUE KEY table_line.

DATA num TYPE i VALUE 400.
DATA dref TYPE REF TO i.
DATA cond TYPE string.

DO 30 TIMES.
  line-col1 = sy-index.
  line-col2 = sy-index ** 2.
  APPEND line TO itab.
ENDDO.

GET REFERENCE OF num INTO dref.

LOOP AT itab INTO line FROM 10 TO 25 WHERE col2 > dref->*.
  WRITE / line-col2.
ENDLOOP.

SKIP.

cond = 'col2 > dref->*'.

LOOP AT itab INTO line FROM 10 TO 25 WHERE (cond).
  WRITE / line-col2.
ENDLOOP.

General Material Data   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.


Length: 21600 Date: 20120526 Time: 214512     triton ( 520 ms )