Kontakt

Ansicht
Dokumentation

ABAPMODIFY_ITAB_MULTIPLE - MODIFY ITAB MULTIPLE

ABAPMODIFY_ITAB_MULTIPLE - MODIFY ITAB MULTIPLE

Addresses (Business Address Services)   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

MODIFY itab, itab_lines

Kurzreferenz



... itab FROM wa $[USING KEY keyname$]
         TRANSPORTING comp1 comp2 ... WHERE log_exp$|(cond_syntax).

Zusätze:

1. ... WHERE log_exp

2. ... USING KEY keyname

3. ... WHERE (cond_syntax)

Wirkung

In dieser Variante weist die Anweisung MODIFY allen Zeilen der Tabelle itab, welche die Bedingung hinter WHERE erfüllen, den Inhalt der hinter TRANSPORTING angegebenen Komponenten comp1 comp2 ... des Arbeitsbereichs wa zu. Bei wa handelt es sich um eine funktionale Operandenposition. Der Arbeitsbereich wa muss kompatibel zum Zeilentyp der internen Tabelle sein.

Der Zusatz TRANSPORTING wirkt wie beim Ändern einzelner Zeilen. Der Zusatz WHERE kann nur gemeinsam mit dem TRANSPORTING-Zusatz angegeben werden.

Hinweis

Außerhalb von Klassen gibt es noch eine obsolete Kurzform, bei der die Angabe FROM wa weggelassen werden kann, falls die interne Tabelle eine gleichnamige Kopfzeile itab hat. Die Anweisung verwendet dann implizit die Kopfzeile als Arbeitsbereich. Ohne FROM wa kann USING KEY auch nicht angegeben werden.

Zusatz 1

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


Beispiel

Die MODIFY-Anweisung ersetzt in der internen Tabelle itab in der Spalte col2 jeden negativen Wert durch die Zahl 0.

Zusatz 2

... 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 die WHERE-Bedingung optimierbar sein, sonst kommt es zu einem Syntaxfehler oder einer Ausnahme.

Beispiel

Die MODIFY-Anweisung ersetzt in der internen Tabelle itab den Wert in Spalte col1 durch "_" wenn die Spalte col2 den Wert 0 enthält. Die WHERE-Bedingung wird optimiert über den sekundären Schlüssel mkey ausgewertet.

Zusatz 3

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

Wie das Beispiel zur statischen WHERE-Bedingung, hier aber mit dynamisch eingebbarer Bedingung für die Spalte col2.






CPI1466 during Backup   Addresses (Business Address Services)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 15547 Date: 20240523 Time: 142656     sap01-206 ( 236 ms )