Ansicht
Dokumentation

ABAPSELECT_INTO_TARGET - SELECT INTO TARGET

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

SELECT, INTO target

Kurzreferenz

... ${     @dobj       $}
  $| ${     @DATA(dobj)$|@FINAL(dobj) $}
  $| ${ NEW @dref       $}
  $| ${ NEW @DATA(dref)$|@FINAL(dref) $} ...

Alternativen:

1. ... @dobj

2. ... @DATA(dobj)$|@FINAL(dobj)

3. ... NEW @dref

4. ... NEW @DATA(dref)$|@FINAL(dref)

Wirkung

Angabe eines Zielbereichs der INTO-Klausel einer Query in . Mögliche Zielbereiche der INTO-Klausel sind:

• Elementare Datenobjekte elem1, elem2, ... in einer kommaseparierten Liste.

• Einzelne Arbeitsbereiche wa.

• Interne Tabellen itab hinter TABLE.

Jeder Zielbereich kann wie folgt angegeben werden:

• Ohne den Zusatz NEW gibt dobj direkt das Datenobjekt an, in das die Daten aus der Ergebnismenge geschrieben werden. Der Zielbereich ist

• entweder eine bereits deklarierte Hostvariable @dobj

• oder eine mit @DATA inline deklarierte Hostvariable dobj.

Mit dem Zusatz NEW wird ein anonymes Datenobjekt erzeugt, in das die Daten aus der Ergebnismenge geschrieben werden und auf das eine Datenreferenzvariable dref zeigt. Die Datenreferenzvariable ist

• entweder eine bereits deklarierte Hostvariable @dref

• oder eine mit @DATA inline deklarierte Hostvariable dref.

In einer kommaseparierten Liste für elementare Datenobjekte als Zielbereiche können alle Alternativen gemischt auftreten. Bei der Angabe eines einzelnen Arbeitsbereichs oder einer internen Tabelle muss eine der Alternativen ausgewählt werden.

Hinweis

Bei der Variante NEW @DATA(dref)$|@FINAL(dref) können die SELECT-Liste, die FROM-Klausel und eventuelle Indikatoren dynamisch angegeben werden. Dies ist die einzige Möglichkeit, eine dynamisch definierte Ergebnismenge mit Inline-Deklarationen zu kombinieren. Das gleiche gilt für Inline-Deklarationen hinter FETCH.

Alternative 1

... @dobj

Wirkung

Angabe einer bereits deklarierten Hostvariable @dobj als Zielbereich der INTO-Klausel. Die Daten der Ergebnismenge werden direkt in die Hostvariable dobj geschrieben. Je nach Operandenposition kann die Hostvariable sein:

• In der kommaseparierten Liste elem1, elem2, ... ein elementares Datenobjekt, das zum Typ der zugeordneten Spalte der Ergebnismenge passt bzw. in dessen Datentyp der Typ der zugeordneten Spalte der Ergebnismenge konvertiert werden kann.

• Als einzelner Arbeitsbereich wa ein Datenobjekt, das den Voraussetzungen genügt.

• Als interne Tabelle ein beliebige Tabellenart, deren Zeilenstruktur den Voraussetzungen genügt.

Das Schreiben in die Hostvariable erfolgt wie bei der INTO-Klausel beschrieben.

Beispiel

Verwendung verschiedener vorhandener Hostvariablen als Zielbereiche von SELECT-Anweisungen.

Alternative 2

... @DATA(dobj)$|@FINAL(dobj)

Wirkung

Angabe einer inline deklarierten Hostvariable dobj als Zielbereich der INTO-Klausel. Die Daten der Ergebnismenge werden direkt in die Hostvariable dobj geschrieben. Die Inline-Deklaration erfolgt mit einem der Deklarationsoperatoren DATA oder FINAL, dem hier das Fluchtsymbol @ vorangestellt werden muss. Je nach Operandenposition wird die Hostvariable wie folgt deklariert:

• In der kommaseparierten Liste elem1, elem2, ... wird eine elementare Variable deklariert. Der Datentyp der Variablen wird wie folgt aus der zugeordneten Spalte der Ergebnismenge konstruiert:

• Für eine Spalte einer Datenquelle wird der ABAP-Typ verwendet, der deren Dictionary-Typ zugeordnet ist.

• Für einen SQL-Ausdruck wird der ABAP-Typ verwendet, der dessen Ergebnistyp zugeordnet ist.

• Für eine einzelne als SQL-Ausdruck angegebene Hostvariable wird direkt deren ABAP-Typ verwendet.

• Als einzelner Arbeitsbereich bei INTO @DATA(wa) oder INTO @FINAL(wa) wird ein flaches Datenobjekt wa deklariert. Als interne Tabelle bei INTO TABLE @DATA(itab) INTO TABLE @FINAL(itab) wird eine Standardtabelle itab mit leerem Tabellenschlüssel deklariert. Der Datentyp von wa bzw. der Zeilentyp der internen Tabelle werden wie folgt gemäß der Struktur der hinter SELECT definierten Ergebnismenge und der Anzahl der hinter FROM angegebenen Datenquellen konstruiert:

• Wird die Ergebnismenge in der SELECT-Liste durch eine einzige Spaltenangabe col_spec definiert, für die kein Name festgestellt werden kann, ist der Datentyp von wa bzw. der Zeilentyp von itab dessen elementarer Typ.

• Wird die Ergebnismenge in der SELECT-Liste durch eine einzige Spaltenangabe col_spec definiert, für die ein Name festgestellt werden kann, ist der Datentyp von wa bzw. der Zeilentyp von itab eine Struktur mit einer Komponente, mit deren elementaren Typ.

• Wird die Ergebnismenge in der SELECT-Liste durch eine einzelnes data_source~* oder eine Liste mehrerer Spaltenangaben col_spec definiert, ist der Datentyp von wa bzw. der Zeilentyp von itab eine Struktur mit elementaren Komponenten. Die Datentypen der Komponenten sind die elementaren Typen der Spalten der Ergebnismenge in der dort festgelegten Reihenfolge.

• Wenn data_source~* in der SELECT-Liste gemeinsam mit anderen Elementen aufgeführt ist, ist der Datentyp von wa bzw. der Zeilentyp von itab eine geschachtelte Struktur. Für jede solcherart angegebene Datenquelle data_source wird eine Unterstruktur mit dem Namen bzw. Aliasnamen der Tabelle bzw. View erzeugt. Die Datentypen der Komponenten der Unterstrukturen sind die elementaren Typen der Datenquelle in der dort festgelegten Reihenfolge. Wenn die Datenquelle ein mit WITH deklarierter allgemeiner Tabellenausdruck ist, wird das erste Zeichen + dessen Namens nicht für den Namen der Unterstruktur berücksichtigt.

• Wird die Ergebnismenge in der SELECT-Liste durch * definiert hängt der Datentyp von der Anzahl der hinter FROM angegebenen Datenquellen ab:

Beim Lesen aus einer einzelnen Datenquelle data_source ist der Datentyp von wa bzw. der Zeilentyp von itab wie bei einer Definition der Ergebnismenge über ein einzelnes data_source~* (siehe oben), d.h. eine Struktur mit elementaren Komponenten.

Beim Lesen aus mehreren Datenquellen data_source1, data_source2, ... über einen Join ist der Datentyp von wa bzw. der Zeilentyp von itab wie bei einer Definition der Ergebnismenge über data_source1~*, data_source2~*, ... (siehe oben), d.h. eine Struktur mit einer Unterstruktur für jede Datenquelle.

• Die Namen der elementaren Komponenten einer Struktur entsprechen denen der zugehörigen Spalten aus der Ergebnismenge, wobei die dort definierte Aliasnamen berücksichtigt werden.

• Der elementare Datentyp eines elementaren Datenobjekts bzw. einer elementaren Komponente einer Struktur wird wie bei einem elementaren Datenobjekt in einer kommaseparierten Liste aus dem Typ der zugeordneten Spalte der Ergebnismenge konstruiert (siehe oben).

• Wenn der Zusatz INDICATORS verwendet wird, wird am Ende der inline deklarierten Struktur bzw. Zeilenstruktur eine Unterstruktur mit dem Namen null_ind hinzugefügt wird. Diese Unterstruktur enthält für jede Spalte der Ergebnismenge in der gleichen Reihenfolge eine gleichnamige Komponente vom Typ x der Länge 1. Wenn vorhergehende Komponenten der inline deklarierten Struktur Unterstrukturen sind, ist auch die Unterstruktur null_ind entsprechend strukturiert.

Voraussetzungen für eine Inline-Deklaration sind:

• Eine dynamische Angabe der Ergebnismenge ist nur zusammen mit dem Zusatz NEW möglich. Wenn der Zusatz NEW nicht angegeben ist, muss die Struktur der Ergebnismenge statisch erkennbar sein. Die SELECT-Liste und eventuelle Indikatoren müssen statisch angegeben sein.

• Hinter FETCH kann eine Inline-Deklaration nur zusammen mit dem Zusatz NEW vorgenommen werden.

• Die in der SELECT-Liste definierte Ergebnismenge darf nicht mehrere Spalten mit gleichen Namen haben, was über Aliasnamen umgangen werden kann.

• In einer mehrspaltigen Ergebnismenge oder wenn der Zusatz INDICATORS angegeben ist muss jeder SQL-Ausdruck und jeder Aggregatausdruck einen Aliasnamen haben.

• Aliasnamen der SELECT-Liste müssen den Namenskonventionen für programminterne Bezeichner genügen. Insbesondere dürfen sie kein Minuszeichen - enthalten.

• Wenn mit dem obsoleten Zusatz CLIENT SPECIFIED auf eine mandantenabhängige CDS-Entität zugegriffen wird, muss dabei ein Name für die Mandantenspalte angegeben sein.

• Der Zusatz CORRESPONDING FIELDS OF darf nicht verwendet werden.

Hinweise

• Spaltenangaben, für die kein Name festgestellt werden kann, sind SQL- und Aggregatausdrücke ohne Aliasnamen.

• Bei der Angabe einer Inline-Deklaration @DATA(itab) oder @FINAL(itab) hinter APPENDING TABLE wirkt dieser Zusatz in aller Regel wie INTO TABLE und ist in dieser Kombination deshalb nicht sinnvoll.

• Die Verwendung einer Inline-Deklaration bedingt, dass die Syntaxprüfung in einem strikten Modus ausgeführt wird, welche die Anweisung strenger behandelt als die normale Syntaxprüfung.

Beispiel

Einlesen einzelner Spalten einer Ergebnismenge in verschiedene inline deklarierte Zielbereiche. carrname, carrid und url sind elementare Datenobjekte. wa ist eine Struktur mit elementaren Komponenten. itab ist eine Standardtabelle mit entsprechendem Zeilentyp.

Beispiel

Einlesen aller Spalten der Ergebnismenge eines inneren Joins in eine interne Tabelle, deren Zeilentyp inline als geschachtelte Struktur mit dem gleichen Aufbau wie die Ergebnismenge deklariert wird. Die erste Komponente der geschachtelten Struktur heißt SCARR und umfasst alle Spalten dieser DDIC-Datenbanktabelle. Die zweite Komponente der geschachtelten Struktur heißt SPFLI und umfasst alle Spalten dieser DDIC-Datenbanktabelle. Der Inhalt der Spalten MANDT und CARRID beider Tabellen ist redundant vorhanden. Für die Ausgabe wird die interne Tabelle mit geschachteltem Zeilentyp in eine Ausgabetabelle ohne Unterstrukturen konvertiert.

Inline-Deklarationen

Alternative 3

... NEW @dref

Wirkung

Der Zusatz NEW erzeugt ein anonymes Datenobjekt als Zielbereich der INTO-Klausel. Für dref muss eine bereits deklarierte Datenreferenzvariable angegeben werden, die nach der Erzeugung des Datenobjekts auf dieses zeigt. Die Daten der Ergebnismenge werden in das erzeugte anonyme Datenobjekt geschrieben. Die Datenreferenzvariable dref kann vollständig oder generisch typisiert sein.

• Wenn die Datenreferenzvariable dref vollständig typisiert ist, muss ihr statischer Typ den gleichen Regeln, wie für den Typ eines direkt angegebenen Datenobjekts @dobj genügen:

• In einer kommaseparierten Liste (..., dref, ...) muss es ein elementarer Datentyp sein, in den der Typ der zugeordneten Spalte der Ergebnismenge konvertiert werden kann.

• In einem einzelnen Arbeitsbereich wa muss der Typ den Voraussetzungen für Arbeitsbereiche genügen.

• Als interne Tabelle muss es ein Tabellentyp beliebiger Tabellenart sein, dessen Zeilenstruktur den Voraussetzungen genügt.

Das anonyme Datenobjekt wird mit dem Typ der Datenreferenzvariable erzeugt. Der statische Typ der Datenreferenzvariable entspricht dem dynamischen Typ. Das Schreiben in das anonyme Datenobjekt erfolgt wie bei der INTO-Klausel beschrieben.

• Wenn die Datenreferenzvariable dref generisch mit data typisiert ist wird der Datentyp des anonymen Datenobjekts bzw. der dynamische Typ von dref in Abhängigkeit von der Operandenposition genauso konstruiert, wie der Datentyp von dobj bei der oben beschriebenen Inline-Deklaration @DATA$|FINAL(dobj), d.h.: Dies bedeutet:

• In einer kommaseparierten Liste (..., dref, ...) wird ein elementares Datenobjekt erzeugt, dessen Typ durch den Typ der zugeordneten Spalte der Ergebnismenge bestimmt wird.

• In einem einzelnen Arbeitsbereich bei INTO NEW @dref wird ein flaches Datenobjekt erzeugt. Als interne Tabelle bei INTO TABLE NEW @dref wird eine Standardtabelle mit leerem Tabellenschlüssel erzeugt. Der Typ des erzeugten Datenobjekts oder der Zeilentyp der internen Tabelle wird wie bei einer Inline-Deklaration mit @DATA$|FINAL(dobj) konstruiert.

Das anonyme Datenobjekt wird mit diesem Typ erzeugt. Der statische Typ der Datenreferenzvariable ist allgemeiner als der dynamische Typ. Das Schreiben in das anonyme Datenobjekt erfolgt wie bei der INTO-Klausel beschrieben. Die in der SELECT-Liste definierten Spalten der Ergebnismenge müssen eindeutige Namen haben.

Im Unterschied zu einer Inline-Deklarationen mit @DATA|FINAL(dobj) kann der Typ des anonymen Datenobjekts auch zur Laufzeit erzeugt werden. Deshalb kann der Zusatz NEW auch in folgenden Fällen angegeben werden:

• Wenn die Struktur der Ergebnismenge wegen der Verwendung dynamischer Tokens nicht statisch erkennbar ist.

• Hinter FETCH.

Die Typprüfung findet falls möglich bei der Syntaxprüfung und ansonsten zur Laufzeit statt. Falls ein Fehler erst zur Laufzeit festgestellt wird, kommt es zu einer Ausnahme der Klasse CX_SY_DYNAMIC_OSQL_SEMANTICS.

Dabei gibt es folgende Einschränkungen:

• Der Zusatz NEW kann nur hinter INTO aber nicht hinter APPENDING angegeben werden.

• Wenn mehrere FETCH-Anweisungen auf einen mit OPEN CURSOR geöffneten Datenbank-Cursor zugreifen, darf eine hinter NEW verwendete Datenreferenzvariable nur dann generisch typisiert sein, wenn auch die erste dieser FETCH-Anweisungen an der entsprechenden Operandenposition den Zusatz NEW mit generisch typisierter Datenreferenzvariable hat.

Hinweise

• Der Zusatz NEW wirkt ähnlich wie die Erzeugung eines anonymen Datenobjekts mit dem Instanziierungsoperator NEW direkt vor der -Anweisung und der Verwendung der dereferenzierten Referenzvariable als Zielbereich. Der Vorteil des Zusatzes NEW ist, dass der Datentyp des anonymen Datenobjekts passend konstruiert wird und dass dies insbesondere auch für dynamische Tokens funktioniert.

• Bei Verwendung des Zusatzes NEW wird die Syntaxprüfung im strikten Modus ab Release ausgeführt.

Beispiel

Verwendung einer generisch typisierten und einer vollständig typisierten Datenreferenzvariable hinter NEW. Die beiden erzeugten anonymen Datenobjekte haben beide den gleichen Typ und den gleichen Inhalt. Die dritte SELECT-Anweisung schreibt in ein zuvor mit dem Instanziierungsoperator NEW erzeugtes anonymes Datenobjekt und zeigt damit in etwa die Funktionsweise des NEW-Zusatzes.

Beispiel

In diesem Beispiel werden drei anonyme Datenobjekte vom Typ string erzeugt. Die Spalten der Ergebnismenge werden nach string konvertiert.

Beispiel

Das Beispiel vergleicht eine INTO-Klausel mit einer Inline-Deklaration des Zielbereichs (siehe oben) mit einer INTO-Klausel mit dem Zusatz NEW. In beiden Fällen wird der gleiche Datentyp, nämlich eine interne Tabelle mit geschachtelter Zeilenstruktur konstruiert. Solange nicht auf einzelne Komponenten zugegriffen werden soll, muss der genaue Datentyp im Programm nicht bekannt sein.

Beispiel

Wie das vorhergehende Beispiel aber hinter FETCH und mit dynamischer Angabe der SELECT-Liste und der FROM-Klausel hinter OPEN CURSOR. In diesem Fall ist keine direkte Inline-Deklaration des Zielbereichs in der INTO-Klausel möglich. Der Zusatz NEW kann dagegen verwendet werden.

Beispiel

Das Programm DEMO_SELECT_INTO_NEW_VARIANTS zeigt die Verwendung des NEW-Zusatzes in verschiedenen Varianten der INTO-Klausel.

Alternative 4

... NEW @DATA(dref)$|@FINAL(dref)

Wirkung

Der Zusatz NEW vor einer Inline-Deklaration mit den Deklarationsoperatoren @DATA oder @FINAL funktioniert wie die vorhergehende Variante, mit dem Unterschied, dass die Datenreferenzvariable dref, die auf das erzeugte anonyme Datenobjekt zeigt, inline deklariert wird. Der statische Typ der Datenreferenzvariable dref wird wie folgt festgelegt:

• Wenn der Datentyp des erzeugten anonymen Datenobjekts statisch erkennbar ist, wird auch dref mit diesem Typ typisiert.

• Wenn der Datentyp des erzeugten anonymen Datenobjekts erst zur Laufzeit erkennbar ist, wird dref mit dem generischen Typ data typisiert. Dies ist dann der Fall, wenn die Struktur der Ergebnismenge wegen der Verwendung dynamischer Tokens nicht statisch erkennbar ist sowie bei Inline-Deklarationen hinter FETCH.

Die in der SELECT-Liste definierten Spalten der Ergebnismenge müssen eindeutige Namen haben. Wenn mehrere FETCH-Anweisungen auf einen mit OPEN CURSOR geöffneten Datenbank-Cursor zugreifen, dürfen NEW und eine Inline-Deklaration nur dann verwendet werden, wenn dies auch in der ersten dieser FETCH-Anweisungen an der entsprechenden Operandenposition der Fall ist.

Hinweis

Mit dem Zusatz NEW ist eine Inline-Deklaration auch zusammen mit dynamischen Tokens und hinter FETCH möglich. Es wird aber nicht der direkte Zielbereich sondern die Datenreferenzvariable deklariert, die auf den als anonymes Datenobjekt erzeugten Zielbereich zeigt.

Beispiel

Erzeugung anonymer Datenobjekte als Zielbereiche zusammen mit Inline-Deklarationen der Datenreferenzvariablen. Während die Datenreferenzvariable dref_scarr hinter SELECT mit statischen Tokens den statischen Typ einer internen Tabelle mit dem Zeilentyp SCARR aus dem ABAP Dictionary hat, wird dref_data hinter FETCH generisch mit data typisiert. Dies wird durch Verwendung von RTTI-Methoden gezeigt.

• Struktur als Zielbereich erzeugen

• Interne Tabelle als Zielbereich erzeugen
  
  

General Material Data   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 29939 Date: 20240523 Time: 124310     sap01-206 ( 410 ms )