Ansicht
Dokumentation

ABAPINSERT_SOURCE - INSERT SOURCE

ABAPINSERT_SOURCE - INSERT SOURCE

General Data in Customer Master   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

INSERT dbtab, source

Kurzreferenz



...  @wa$|@( expr )
  $| ${ TABLE @itab$|@( expr ) $[ACCEPTING DUPLICATE KEYS$] $}
  $| ( SELECT subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...

Alternativen:

1. ... @wa$|@( expr ) ...

2. ... TABLE @itab$|@( expr ) $[ACCEPTING DUPLICATE KEYS$] ...

3. ... ( SELECT subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...

Wirkung

Hinter den Zusätzen VALUES und FROM der Anweisung INSERT können als Datenquelle ein nicht-tabellenartiges Datenobjekt als Hostvariable @wa oder als Hostausdruck @( expr ) angegeben werden. Hinter FROM TABLE kann eine interne Tabelle oder eine Subquery angegeben werden. Die interne Tabelle kann ebenfalls als Hostvariable @itab oder als Hostausdruck @( expr ) angegeben werden. Der Inhalt der einzufügenden Zeile(n) wird diesen Datenobjekten oder der Ergebnismenge der Subquery entnommen.

Hinweis

Die Angabe von Hostvariablen ohne Fluchtsymbol @ ist obsolet. In den strikten Modi der Syntaxprüfung ab Release muss das Fluchtsymbol @ angegeben werden.

Alternative 1

... @wa$|@( expr ) ...


Wirkung

Hinter VALUES und FROM kann ein nicht-tabellenartiger Arbeitsbereich als Hostvariable @wa oder als Hostausdruck @( expr ) angegeben werden, aus dessen Inhalt eine Zeile zum Einfügen in die DDIC-Datenbanktabelle aufgebaut wird. Der Arbeitsbereich muss die Voraussetzungen für die Verwendung in-Anweisungen erfüllen.

  • Bei der Angabe eines Arbeitsbereichs, der keine Referenzvariablen für LOB-Handles enthält, wird der Inhalt der einzufügenden Zeile dem Arbeitsbereich wa ohne Berücksichtigung seines Datentyps von links nach rechts gemäß der Struktur der DDIC-Datenbanktabelle bzw. View entnommen. Es findet keine Konvertierung in den ABAP-Typ statt, der einer Spalte über deren Dictionary-Typ zugeordnet ist.
  • Bei der Angabe einer LOB-Handle-Struktur muss diese gemäß den Voraussetzungen genau wie die Struktur der DDIC-Datenbanktabelle aufgebaut sein. Die Komponenten des Arbeitsbereichs, die keine LOB-Handle-Komponenten sind, werden direkt den entsprechenden Spalten der neuen Zeile zugewiesen. Wenn es sich um eine LOB-Handle-Komponente vom Typ eines Schreibstroms handelt, wird dieser erzeugt. Wenn es sich um einen Typ für einen Lokator handelt, muss dieser vorhanden sein und wird als Quelle verwendet. Für Details, siehe LOB-Handles.

Die neue Zeile wird in die DDIC-Datenbanktabelle eingefügt, wenn es dort noch keine Zeile mit dem gleichen Primärschlüssel bzw. einem gleichen eindeutigen Sekundärindex gibt. Ansonsten wird die Zeile nicht eingefügt und sy-subrc auf 4 gesetzt. Beim Einfügen der Zeile werden die den einzelnen Spalten der DDIC-Datenbanktabelle zugeordneten Inhalte des Arbeitsbereichs von der Datenbankschnittstelle auf deren Datentypen gemappt und gegebenenfalls konvertiert. Bei unpassenden Inhalten kann es zu Ausnahmen durch Überläufe oder ungültige Werte kommen.

Wenn in target eine View angegeben ist, die nicht alle Spalten der DDIC-Datenbanktabelle umfasst, werden diese in den eingefügten Zeilen entweder auf ihren typabhängigen Initialwert oder auf den Null-Wert gesetzt. Letzteres ist nur dann der Fall, wenn für die betreffenden Spalten der DDIC-Datenbanktabelle nicht die Eigenschaft NOT NULL in der Datenbank gesetzt ist.

Hinweise

  • Der Arbeitsbereich wa sollte immer mit Bezug auf die DDIC-Datenbanktabelle bzw. den DDIC-View im ABAP Dictionary deklariert werden. Für die Ableitung von LOB-Handle-Strukturen gibt es spezielle Zusätze zu den Anweisungen TYPES und $[CLASS-$]DATA.
  • Bei kompatiblen Arbeitsbereichen kann es zu Ausnahmen wegen ungültiger Werte kommen. Beispielsweise können Komponenten der Typen d und t ungültige Datums- und Zeitangaben enthalten, die nicht von Spalten der Typen DATN und TIMN akzeptiert werden.
  • Bei statischer Angabe der DDIC-Datenbanktabelle bzw. des DDIC-Views ist außerhalb von Klassen noch eine obsolete Kurzform möglich, bei der die Angabe des Arbeitsbereichs mit FROM wa in der Variante ohne INTO weggelassen werden kann, falls mit der Anweisung TABLES ein Tabellenarbeitsbereich dbtab für die entsprechende DDIC-Datenbanktabelle bzw. für den DDIC-View deklariert ist. Das Laufzeit-Framework ergänzt die INSERT-Anweisung dann implizit um den Zusatz FROM dbtab.

Beispiel

Einfügen einer neuen Fluggesellschaft in die DDIC-Datenbanktabelle SCARR über einen Arbeitsbereich wa.

Beispiel

Einfügen einer neuen Fluggesellschaft in die DDIC-Datenbanktabelle SCARR mit dem Wertoperator VALUE in einem Hostausdruck.

Alternative 2

... TABLE @itab$|@( expr ) $[ACCEPTING DUPLICATE KEYS$] ...


Wirkung

Hinter FROM und TABLE kann eine interne Tabelle itab als Hostvariable @itab oder als Hostausdruck @( expr ) angegeben werden, aus deren Inhalt mehrere Zeilen zum Einfügen in die DDIC-Datenbanktabelle aufgebaut werden. Der Zeilentyp der internen Tabelle muss die Voraussetzungen für die Verwendung in -Anweisungen erfüllen.

Der Inhalt jeder Zeile der internen Tabelle wird nach den gleichen Regeln wie bei einem einzelnen Arbeitsbereich wa zu einer einzufügenden Zeile zusammengesetzt, mit der Ausnahme, dass beim Einfügen aus einer internen Tabelle zwar Lokatoren als Quelle dienen aber keine Schreibströme erzeugt werden können.

Falls für keine der einzufügenden Zeilen bereits eine Zeile mit gleichem Primärschlüssel oder einem gleichen eindeutigen Sekundärindex in der DDIC-Datenbanktabelle existiert, werden alle Zeilen eingefügt und sy-subrc wird auf 0 gesetzt. Ist die interne Tabelle leer, werden zwar keine Zeilen eingefügt, sy-subrc wird aber dennoch auf 0 gesetzt. Das Systemfeld sy-dbcnt wird immer auf die Anzahl der tatsächlich eingefügten Zeilen gesetzt.

Falls für eine oder mehrere der einzufügenden Zeilen bereits eine Zeile mit dem gleichen Primärschlüssel oder einem gleichen eindeutigen Sekundärindex in der DDIC-Datenbanktabelle vorhanden ist, können diese Zeilen nicht eingefügt werden. In dieser Situation gibt es folgende Möglichkeiten:

  • Verwendung von ACCEPTING DUPLICATE KEYS
Wenn der Zusatz ACCEPTING DUPLICATE KEYS angegeben ist, werden alle Zeilen eingefügt, für die dies möglich ist. Alle Zeilen, die zu doppelten Einträgen bezüglich des Primärschlüssel oder eines eindeutigen Sekundärindex führen würden, werden verworfen und sy-subrc wird auf 4 gesetzt. Das Systemfeld sy-dbcnt wird immer auf die Anzahl der tatsächlich eingefügten Zeilen gesetzt.
  • Keine Verwendung von ACCEPTING DUPLICATE KEYS
  • Behandlung der Ausnahme CX_SY_OPEN_SQL_DB

Wenn der Zusatz ACCEPTING DUPLICATE KEYS nicht angegeben ist, kommt es beim Einfügen einer doppelten Zeile zur behandelbaren Ausnahme CX_SY_OPEN_SQL_DB. Es werden solange Zeilen eingefügt, bis die Ausnahme auftritt und behandelt wird. Die Anzahl der eingefügten Zeilen ist undefiniert. Die Systemfelder sy-subrc und sy-dbcnt behalten ihren vorhergehenden Wert.
  • Keine Behandlung der Ausnahme CX_SY_OPEN_SQL_DB

Wenn der Zusatz ACCEPTING DUPLICATE KEYS nicht angegeben ist, und die Ausnahme nicht behandelt wird, kommt es beim Einfügen einer doppelten Zeile zu einem Laufzeitfehler. Dabei wird ein Datenbank-Rollback ausgeführt, der alle Änderungen der aktuellen Datenbank-LUW rückgängig macht. Dies gilt insbesondere für Zeilen, die vor dem Auftreten des doppelten Eintrags eingefügt wurden.

Hinweise

  • Der Zusatz ACCEPTING DUPLICATE KEYS bedeutet nicht, dass doppelte Schlüsseleinträge im Wortsinn akzeptiert werden. Insbesondere wird nicht wie bei MODIFY eine Änderung an einem vorhandenen Eintrag vorgenommen. Statt dessen verhindert ACCEPTING DUPLICATE KEYS das Auftreten der zugehörigen Ausnahme und setzt statt dessen den Rückgabewert sy-subrc auf 4.
  • Wenn der Laufzeitfehler beim Einfügen bereits vorhandener Zeilen durch das Behandeln einer Ausnahme statt über den Zusatz ACCEPTING DUPLICATE KEYS verhindert wird, muss man, falls gewünscht, einen programmgesteuerten Datenbank-Rollback veranlassen.
  • Bei Verwendung einer internen Tabelle führt die paketweise Verarbeitung dazu, dass ein zur INSERT-Verarbeitung paralleler Lesezugriff nur einen Teil der einzufügenden Zeilen sieht.

Beispiel

Einfügen mehrerer Zeilen über den Wertoperator VALUE in einem Hostausdruck. Das Beispiel zeigt die beiden Möglichkeiten, wie mit doppelt vorkommenden Zeilen umgegangen werden kann.

Alternative 3

... ( SELECT subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...


Wirkung

Hinter FROM kann eine eingeklammerte Subquery als Datenquelle angegeben werden. Es werden die Zeilen der Ergebnismenge der Subquery eingefügt, die durch deren Klauseln subquery_clauses definiert wird. Um die Ergebnismengen mehrerer Subqueries zu kombinieren, können die Sprachelemente UNION, INTERSECT, und EXCEPT verwendet werden. Dabei gelten spezielle Regeln query_clauses für die Angabe der Klauseln.

Die Anweisung INSERT mit Subquery kann nicht verwendet werden, wenn für die zu füllende Tabelle die Protokollierung eingeschaltet ist. Bei einer Verwendung für eine DDIC-Datenbanktabelle mit eingeschalteter Protokollierung kommt es zur unbehandelbaren Ausnahme DBSQL_DBPRT_STATEMENT. Die entsprechende Warnung von der Syntaxprüfung kann mit dem Pragma ##logging_versus_from_select ausgeschaltet werden. Die Protokollierung wird für eine DDIC-Datenbanktabelle eingeschaltet wenn die entsprechenden technische Attribute der Tabelle und der Profilparameter rec/client passend gesetzt sind.

Bei einer Subquery als Datenquelle sind bezüglich der Mandantenbehandlung der INSERT-Anweisung zwei Fälle zu beachten:

  • Wenn in der Subquery die implizite Mandantenbehandlung der SELECT-Anweisung standardmäßig ausgeführt oder mit dem Zusatz USING CLIENT umgestellt wird, darf die implizite Mandantenbehandlung der INSERT-Anweisung nicht mit dem Zusatz CLIENT SPECIFIED umgeschaltet werden. Die Mandantenspalte einer mit der INSERT-Anweisung gefüllten mandantenabhängigen Datenbanktabelle bzw. Tabellen-View wird unabhängig von der Ergebnismenge der Subquery mit der Kennung des aktuellen bzw., des mit USING CLIENT angegebenen Mandanten gefüllt.
  • Wenn in der Subquery die implizite Mandantenbehandlung der SELECT-Anweisung mit einem der Zusätze USING $[ALL$] CLIENTS $[IN$] umgestellt wird, muss die implizite Mandantenbehandlung der INSERT-Anweisung mit dem Zusatz CLIENT SPECIFIED umgeschaltet werden. In der Ergebnismenge einer solchen Subquery kann es mehrere Mandantenkennungen geben und diese werden in die Mandantenspalte des Ziels der INSERT-Anweisung eingefügt.

Das Einfügen der Daten der Ergebnismenge in die zu füllende DDIC-Datenbanktabelle bzw. DDIC-View erfolgt Spalte für Spalte im Datenbanksystem. Die Zuordnung der Spalten erfolgt über ihre Position. Die Namen der Spalten in der Ergebnismenge spielen keine Rolle. Die einander zugeordneten Spalten müssen die gleichen Typeigenschaften bezüglich eingebautem Datentyp Länge und Anzahl der Nachkommastellen haben, mit folgenden Ausnahmen:

  • Bei den numerischen Typen INT1, INT2, INT4 und INT8 können Spalten mit kleinerem Wertebereich einer Spalte mit größerem Wertebereich zugewiesen werden.
  • Beim numerischen Typ DEC können Spalten mit kleinerer Länge Spalten mit größerer Länge zugewiesen werden. Weiterhin können Spalten mit weniger Nachkommastellen Spalten mit mehr Nachkommastellen zugewiesen werden, wenn die Anzahl der Vorkommastellen ausreichend ist. Die entsprechenden speziellen Typen CURR und QUAN werden dabei wie DEC behandelt.
  • Die numerischen Typen DF16_DEC DF34_DEC werden wie die Zahlen vom Typ DEC behandelt, als die sie abgelegt sind, und es gilt obige Regel bezüglich Längen und Nachkommastellen.
  • Beim zeichenartigen Typ CHAR können Spalten mit kleinerer Länge Spalten mit größerer Länge zugewiesen werden. Die entsprechenden speziellen Typen CLNT, LANG, CUKY und UNIT werden dabei wie CHAR behandelt.

Alle anderen Typen müssen vollständig gleich sein. Dies gilt insbesondere für NUMC und RAW, bei denen die Längen übereinstimmen müssen. Auch können die verschiedenen Arten von Strings nicht kombiniert werden.

Die Anweisung INSERT mit Subquery fügt keine Null-Werte in die zu füllende DDIC-Datenbanktabelle bzw. DDIC-View ein. Einzufügende Null-Werte können in den folgenden Fällen entstehen:

  • wenn ein von der Subquery gelesenes Feld bereits einen Null-Wert enthält.

Statt einen Null-Wert einzufügen, wird in diesen Fällen

  • für Spalten, die keine Schlüsselfelder der zu füllenden DDIC-Datenbanktabelle bzw. DDIC-View sind, der typabhängige Initialwert eingefügt,
  • bei Spalten, die Schlüsselfelder der zu füllenden DDIC-Datenbanktabelle bzw. DDIC-View sind, wird eine abfangbare Ausnahme der Ausnahmeklasse CX_SY_OPEN_SQL_DB ausgelöst. Wenn bereits statisch erkennbar ist, dass Null-Werte in Schlüsselfelder eingefügt werden könnten, kommt es zu einer durch das Pragma null_values ausblendbaren Warnung von der Syntaxprüfung.

Spalten der zu füllenden DDIC-Datenbanktabelle bzw. DDIC-View , für die es keine Spalte in der Ergebnismenge der Subquery gibt, werden ebenfalls mit ihrem typabhängigen Initialwert versorgt.

Wenn alle Zeilen der Ergebnismenge eingefügt werden konnten, wird sy-subrc auf 0 gesetzt. Wenn eine Zeile der Ergebnismenge nicht eingefügt werden kann, da es bereits eine Zeile mit dem gleichen Primärschlüssel bzw. einem gleichen eindeutigen Sekundärindex gibt, werden alle bislang eingefügten Zeilen wieder verworfen und es kommt zu einer abfangbaren Ausnahme der Klasse CX_SY_OPEN_SQL_DB. Wenn die Ergebnismenge der Subquery leer ist, wird keine Zeile eingefügt und sy-subrc auf 4 gesetzt.

Hinweise

  • Die Verwendung einer Subquery ist performanter, als das Einlesen über eine eigenständige SELECT-Anweisung in eine interne Tabelle und die Verwendung der Tabelle als Datenquelle.
  • Anders als beim Einfügen von Zeilen einer internen Tabelle itab ist der Inhalt der geänderten Tabelle bzw. DDIC-View nach Behandlung der Ausnahme CX_SY_OPEN_SQL_DB immer definiert.
  • Für Kombinationen zwischen Spalten, die durch obige Regeln verboten sind, können unter Umständen CAST-Ausdrücke in der SELECT-Liste der Subquery verwendet werden.
  • Da in einer mit * angegebenen SELECT-Liste der Subquery keine Mandantenspalten berücksichtigt werden, kann problemlos auf mandantenabhängige CDS-Entitäten zugegriffen werden, deren Ergebnismenge keine Mandantenspalte hat.
  • Durch die Verwendung von USING CLIENT in der Subquery können dort die Daten eines anderen Mandanten gelesen werden, als für den sie mit INSERT geschrieben werden. Insbesondere können die Daten eines Mandanten in einen anderen Mandanten kopiert werden.
  • Dass es beim Versuch Schlüsselfelder mit Null-Werten zu füllen zu einer Ausnahme kommt, verhindert duplikative Einträge in der zu füllenden Tabelle bzw. DDIC-View .
  • DDIC-Datenbanktabellen und DDIC-Views , auf die mit dieser Variante der INSERT-Anweisung zugegriffen wird, sollten nicht unabhängig voneinander erweitert werden, um Syntaxfehler zu vermeiden.
  • Um die Ausnahme beim Schreiben in eine DDIC-Datenbanktabelle mit eingeschalteter Protokollierung zu vermeiden, kann die Methode IS_LOGGING_ON der Systemklasse CL_DBI_UTILITIES verwendet werden, um zu einer alternativen Implementierung zu verzweigen.
  • Bei der Verwendung einer Subquery wird die Syntaxprüfung im strikten Modus ab Release ausgeführt, welche die Anweisung strenger behandelt als die normale Syntaxprüfung.
  • Bei der Verwendung von USING CLIENT oder einem Zugriff auf die Tabelle oder View , die mit der INSERT-Anweisung gefüllt wird, in der Subquery wird die Syntaxprüfung im strikten Modus ab Release ausgeführt, welche die Anweisung strenger behandelt als die normale Syntaxprüfung. Die Verwendung von USING $[ALL$] CLIENTS $[IN$] führt zum strikten Modus ab Release .

Beispiel

Einfügen aller Zeilen einer Vereinigungsmenge der DDIC-Datenbanktabellen DEMO_JOIN1 und DEMO_JOIN2 in die Tabelle DEMO_JOIN3. Ein Subquery kann nur dann verwendet werden, wenn die Protokollierung für die Datenbanktabelle DEMO_JOIN3 ausgeschaltet ist. Ansonsten müssen die Daten über die Selektion in eine interne Tabelle eingefügt werden.






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

Length: 28614 Date: 20240328 Time: 211615     sap01-206 ( 398 ms )