Kontakt

Ansicht
Dokumentation

ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

General Data in Customer Master   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

DELETE itab, itab_lines

Kurzreferenz



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

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

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

Zusatz 1

... USING KEY keyname

Wirkung

Mit dem Zusatz USING KEY kann in keyname ein Tabellenschlüssel angegeben werden, 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 übrigen Bedingungen.

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

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.

Hinweise

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

Die Anweisung DELETE löscht die ersten drei Zeilen der internen Tabelle itab, da diese im sekundären Tabellenindex des verwendeten Sekundärschlüssel skey ab Zeile 4 vorkommen.

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.

Die Zusätze FROM und TO können zusammen mit STEP angegeben werden und es gelten dann spezielle Regeln.

Hinweis

Zu einer Anweisung DELETE FROM itab gibt es eine syntaktisch gleiche Anweisung DELETE FROM dbtab. Wenn eine interne Tabelle den gleichen Namen wie eine Datenbanktabelle hat, greift eine solche Anweisung auf die interne Tabelle zu.

Beispiel

Löschen aller Zeilen einer internen Tabelle ab Zeile 4. Das Ergebnis ist das Gleiche wie im Beispiel zu APPEND ... SORTED BY.

Zusatz 3

... STEP n

Wirkung

Mit dem optionalen Zusatz STEP wird die Schrittgröße für eine interne Tabelle definiert. Die Schrittgröße wird mit dem Wert von ndefiniert, der positiv sein muss. n ist eine numerische Ausdrucksposition vom Operandentyp i. Falls der Zusatz STEP nicht angegeben wird, ist die Schrittgröße 1.

Die Schrittgröße darf mit den Zusätzen FROM und TO kombiniert werden und wirkt dann auf die Untermenge von durch diese Bedingungen definierten Tabellenzeilen. Falls FROM idx1 und TO idx2 mit STEP kombiniert werden, muss idx1 kleiner gleich idx2 sein.

Abhängig vom Wert von n wird jede n-te Zeile verarbeitet. Der Wert von n darf nicht 0 sein. Mehr Details sind unter LOOP AT itab, cond zu finden.

Hinweise

  • STEP n darf nicht mit WHERE kombiniert werden.
  • Anders als beim Zusatz STEP für LOOP AT, kann hier die Verarbeitungsreihenfolge durch negative Werte von n nicht geändert werden. Die Verarbeitungsreihenfolge wird nur durch die Tabellenart oder den Zusatz USING KEY definiert.
  • STEP n kann aber anders positioniert werden. Die Verwendung hinter FROM idx1 und TO idx2 ist empfohlen.

Beispiel

Im folgenden Beispiel wird gezeigt, dass jede zweite Tabellenzeile zwischen Zeile 1 und Zeile 8 aus der internen Tabelle gelöscht wird.

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.
  • Eine Optimierung der WHERE-Bedingung wirkt sich zwar auf die Suche nach den zu löschenden Zeilen, aber beispielsweise nicht auf die Aktualisierung des Primärindex einer Standardtabelle aus.

Beispiel

Optimiertes Löschen einer Zeile über Angabe des eindeutigen primären Tabellenschlüssels und mehrerer Zeilen über die Angabe eines nicht eindeutigen sekundären Tabellenschlüssels in zwei DELETE-Anweisungen.

Zeilen über WHERE löschen

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

Löschen der Zeilen einer internen Tabelle über eine eingebbare Bedingung für die Tabellenzeilen.






Vendor Master (General Section)   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 21869 Date: 20240425 Time: 102626     sap01-206 ( 374 ms )