ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

Addresses (Business Address Services)   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

DELETE itab - itab_lines

Kurzreferenz

Syntax

... itab [USING KEY keyname] [FROM idx1] [TO idx2]
                            [WHERE log_exp|(cond_syntax)] ... .

Zusätze:

1. ... USING KEY keyname

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

3. ... WHERE log_exp

4. ... WHERE (cond_syntax)

Wirkung

Für das Löschen mehrerer Zeilen muss mindestens einer der Zusätze FROM, TO oder WHERE angegeben werden. Mit USING KEYkeyname wird der Tabellenschlüssel bestimmt, auf den sich die Zusätze beziehen.

Wenn mehrere der Zusätze angegeben sind, werden die Zeilen gelöscht, die sich aus der Schnittmenge der einzelnen Zusätze ergeben.

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 Zeilen über Schlüssel löschen

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.
  
  
  

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.
  
  
  

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

Löschen aller Zeilen einer internen Tabelle ab Zeile 4. Das Ergebnis ist dasselbe wie im Beispielzu APPEND ... SORTED BY.Die Spalte seatsfree ist für die SELECT-Anweisung überflüssig, wird aber im Programm gefüllt. Deshalb wird die zugehörige Warnung der Syntaxprüfung mit dem passendenPragma ausgeblendet.

PARAMETERS: p_carrid TYPE sflight-carrid,
            p_connid TYPE sflight-connid.

DATA: BEGIN OF seats,
        fldate    TYPE sflight-fldate,
        seatsocc  TYPE sflight-seatsocc,
        seatsmax  TYPE sflight-seatsmax,
        seatsfree TYPE sflight-seatsocc,
      END OF seats.

DATA seats_tab LIKE STANDARD TABLE OF seats.

SELECT fldate seatsocc seatsmax
       FROM sflight
       INTO TABLE seats_tab
       WHERE carrid = p_carrid AND
             connid = p_connid ##too_many_itab_fields.

LOOP AT seats_tab INTO seats.
  seats-seatsfree = seats-seatsmax - seats-seatsocc.
  MODIFY seats_tab INDEX sy-tabix FROM seats.
ENDLOOP.

SORT seats_tab BY seatsfree DESCENDING.

DELETE seats_tab FROM 4.

TXBHW - Original Tax Base Amount in Local Currency   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.


Length: 19226 Date: 20120526 Time: 194835     triton ( 519 ms )