Native SQL 

Mit Open SQL kann man unabhängig vom Datenbankhersteller auf alle Datenbanktabellen zugreifen, die im ABAP Dictionary deklariert sind. Native SQL bietet die Möglichkeit, auch datenbankspezifische SQL-Anweisungen in einem ABAP-Programm zu verwenden. Dies erlaubt die Einbindung von Datenbanktabellen, die nicht vom ABAP Dictionary verwaltet werden und ermöglicht so die Integration von Datenbeständen, die unabhängig vom SAP Web AS ABAP entstanden sind.

Ein ABAP-Programm mit datenbankspezifischen SQL-Anweisungen läuft im Allgemeinen nicht auf verschiedenen Datenbanksystemen. Falls ein Programm auf verschiedenen Datenbanksystemen laufen soll, dürfen nur Open SQL-Anweisungen verwendet werden.

Native SQL-Anweisungen in ABAP-Programmen

Um eine Native SQL-Anweisung zu benutzen, müssen ihr die ABAP-Anweisung EXEC SQL vorangestellt und die ABAP-Anweisung ENDEXEC nachgestellt werden:

EXEC SQL [PERFORMING form].
  Native SQL Anweisung
ENDEXEC.

Es ist kein Punkt (.) nach der Native SQL-Anweisung erlaubt. Weiterhin leiten Anführungszeichen (“) in einer Native SQL-Anweisung oder ein Stern (*) am Zeilenanfang nicht wie in der normalen ABAP-Syntax einen Kommentar ein. Bei der Angabe von Namen für Datenbanktabellen und deren  Spalten muss bekannt sein, ob das verwendete Datenbanksystem zwischen Groß- und Kleinschreibung unterscheidet.

Bei Native SQL werden die Daten werden über Hostvariablen zwischen der Datenbanktabelle und dem ABAP-Programm transportiert. Diese Variablen werden im ABAP-Programm deklariert und in der Native SQL-Anweisung wird ihnen ein Doppelpunkt (:) vorangestellt. Als Hostvariablen können Sie elementare Strukturen verwendet werden. Strukturen werden als Sonderfall in einer INTO-Klausel so behandelt, als seien alle ihre Felder einzeln aufgelistet.

Ist die Selektion einer Native SQL SELECT-Anweisung eine Tabelle, kann sie mit dem Zusatz PERFORMING Zeile für Zeile an ABAP übergeben werden. Für jede gelesene Zeile wird ein Unterprogramm form einmal aufgerufen. Innerhalb des Unterprogramms können die gelesenen Daten dann weiterverarbeitet werden.

Wie in Open SQL enthält sy-dbcnt nach der Anweisung ENDEXEC die Anzahl der bearbeiteten Zeilen. sy-subrc enthält in fast allen Fällen nach der Anweisung ENDEXEC den Wert 0. Ausnahmen sind Cursoroperationen: nach FETCH ist sy-subrc 4, wenn kein Satz mehr gelesen werden konnte. Dies gilt auch nach Auslesen einer Ergebnismenge über EXEC SQL PERFORMING.

REPORT demo_native_sql.

DATA: BEGIN OF wa,
        connid   TYPE spfli-connid,
        cityfrom TYPE spfli-cityfrom,
        cityto   TYPE spfli-cityto,
      END OF wa.

DATA c1 TYPE spfli-carrid VALUE 'LH'.

EXEC SQL PERFORMING loop_output.
  SELECT connid, cityfrom, cityto
  INTO   :wa
  FROM   spfli
  WHERE  carrid = :c1
ENDEXEC.

FORM loop_output.
  WRITE: / wa-connid, wa-cityfrom, wa-cityto.
ENDFORM.

Die Listenausgabe ist etwa:

 

Es werden der Arbeitsbereich wa und das Feld c1 Native SQL-Anweisung SELECT verwendet. wa ist der Zielbereich, in den die selektierten Daten geschrieben werden. Als Struktur wird wa für in der INTO-Klausel so behandelt, als seien alle Teilfelder einzeln aufgelistet: [..] INTO :wa-connid, :wa-cityfrom, :wa-cityto. c1 wird in der WHERE-Klausel verwendet. Im Unterprogramm loop_output werden die Daten, die jeweils in wa stehen, auf die Liste geschrieben.

Umfang von Native SQL

Native SQL erlaubt die Ausführung (fast) aller Anweisungen, die von der Datenbank und deren SQL-Programmierschnittstelle (meist mit SQL Call Interface oder ähnlich bezeichnet) für die direkte Ausführung eines SQL-Programmtextes (über EXEC IMMEDIATE oder einen ähnlichen Befehl) angeboten werden. Eine Liste nicht unterstützter Anweisungen findet sich in den folgenden Abschnitten.

Native SQL und die Datenbankschnittstelle

Eine Native SQL-Anweisung umgeht weitgehend die Datenbankschnittstelle: Es erfolgt keine Tabellenprotokollierung und es findet keine Synchronisation mit dem Datenbankpuffer auf dem Applikationsserver statt. Im ABAP Dictionary bekannte Datenbanktabellen sollten daher möglichst nicht über Native SQL sondern über Open SQL geändert werden. Insbesondere falls eine im ABAP Dictionary deklarierte Tabelle lange Spalten der Typen LCHR und LRAW enthält, sollte nur über Open SQL auf sie zugegriffen werden, da für diese Feldern zusätzliche datenbankabhängige Längeninformationen in der Spalte abgelegt sind, die das Ergebnis mit Native SQL verfälschen können. Es gibt weiterhin keine automatische Mandantenbehandlung im Native SQL, sondern ein Mandantenfeld muss wie jedes andere Feld auch behandelt werden.

Native SQL und Transaktionen

Um ein konsistentes Transaktionsverhalten zu erhalten, sollten keine Anweisungen zur Steuerung der Transaktionsbearbeitung (COMMIT, ROLLBACK, ...) und keine Anweisungen zum Setzen von Transaktionsparametern (Isolation Level, ...) über  Native SQL erfolgen.

Stored Procedures

Zur Angleichung der spezifischen Syntax einzelner Datenbankprodukte definiert ABAP eine einheitliche Schreibweise:

EXECUTE PROCEDURE name ( parameterliste )

Parameter werden durch Kommas (,) getrennt. Hinzu kommt die Angabe, ob es sich um Eingabe- (IN), Ausgabe- (OUT) oder Ein- und Ausgabeparameter (INOUT) handelt. Näheres findet man im SAPNet-Hinweis 44977.

EXEC SQL.
   EXECUTE PROCEDURE proc1 ( IN :x, OUT :y )
ENDEXEC.

Cursorverarbeitung

Die Cursorverarbeitung über Native SQL ähnelt Open SQL:

·           OPEN cursorname FOR anweisung

·           FETCH NEXT cursorname INTO zielfeld(er)

·           CLOSE cursorname

EXEC SQL.
  OPEN c1 FOR
    SELECT client, arg1, arg2 FROM table_001
     WHERE client = '000' AND arg2 = :arg2
ENDEXEC.
DO.
  EXEC SQL.
    FETCH NEXT c1 INTO :wa-client, :wa-arg1, :wa-arg2
  ENDEXEC.
  IF sy-subrc <> 0.
    EXIT.
  ELSE.
    ...
  ENDIF.
ENDDO.
EXEC SQL.
  CLOSE c1
ENDEXEC.

Es wird ein Cursor geöffnet, satzweise ausgelesen und schließlich wieder geschlossen. Analog zu Open SQL zeigt sy-subrc an, ob ein weiterer Satz zur Verarbeitung gelesen werden konnte.

Datentypen und Konvertierungen

Native SQL unterstützt die beiden Richtungen

·        Werte von ABAP-Feldern in der Datenbank abzulegen

·        Daten aus der Datenbank auszulesen und in ABAP-Programmen zu verarbeiten

Native SQL arbeitet ohne die Informationen des ABAP Dictionary über Datenbanktabellen und kann daher nicht alle aus Open SQL gewohnten Konsistenzprüfungen durchführen. Anwendungsentwicklern kommt damit ein erhöhtes Maß an Verantwortung zu, mit ABAP-Feldern des richtigen Typs zu arbeiten. Dabei sollte man es stets so einrichten, dass sich ABAP-Datentyp und Typ der Datenbankspalte direkt entsprechen.

Ist die Datenbanktabelle nicht im ABAP Dictionary definiert, so kann kein direkter Bezug auf ihren Datentyp genommen werden. Es sollten dann zentral im ABAP Dictionary für alle Anwendungsprogramme eine einheitliche, Typbeschreibung definiert werden.

Ist eine Tabelle im ABAP Dictionary definiert, so ist beim Bezug auf ihre Struktur zu beachten, dass die Feldreihenfolge im ABAP Dictionary nicht zwingend mit der tatsächlichen Reihenfolge der Datenbankspalten übereinstimmt. Ein Lesen aller Spalten mit einem Stern (*) in der SELECT-Klausel in einen entsprechenden Arbeitsbereich würde dann zu unsinnigen Resultaten führen, die schlimmstenfalls nicht unmittelbar als fehlerhaft erkannt würden.

Das Native SQL-Modul der Datenbankschnittstelle übergibt dem Datenbanksystem eine Beschreibung von Typ, Größe und Speicherort der verwendeten ABAP-Felder. Die eigentlichen Datenzugriffe und Konvertierungen werden zumeist direkt durch die entsprechenden Operationen des Datenbanksystems ausgeführt; Deren Beschreibung findet man im wesentlichen in den Handbüchern der Programmierschnittstellen des Datenbanksystems. Von Fall zu Fall nimmt das Native SQL-Modul auch weitergehende Verträglichkeitsprüfungen vor.

Die Dokumentation der einzelnen Datenbankhersteller listet im Detail Kombinationen aus ABAP-Datentypen und Datenbankspaltentypen auf und zwar für die Speicherung von ABAP-Feldwerten in Datenbanktabellen (INSERT, UPDATE) und das Einlesen von Datenbankinhalten in ABAP-Felder (SELECT). Die Beschreibung können analog auch für den Aufruf von Datenbankprozeduren und deren Eingabe- sowie Ausgabeparameter angewendet werden. Alle dort nicht aufgeführten Kombinationen müssen als undefiniert gelten und sollten nicht verwendet werden.

Die folgenden Abschnitte gehen im Detail auf die Datentypen und Konvertierungen einzelner Datenbanken ein. Obwohl datenbankspezifisch, so finden sich einige Gemeinsamkeiten.

Empfohlene Typkombinationen sind durch Unterstreichung hervorgehoben. Nur deren Verhalten ist Release-unabhängig. Für alle anderen Kombinationen muss davon ausgegangen werden, dass die Beschreibung nur genau für das angegebene Release zutrifft.

Konversionsergebnisse sind in einer Resultatspalte aufgeführt:

·        “ok”: die gewünschte Konvertierung wird ohne Datenverlust durchgeführt

·        Ein Scheitern wird durch den SQL-Fehlercode gekennzeichnet. Ein solcher Fehler führt in jedem Fall zum Programmabbruch und einem ABAP-Kurzdump.

·        In einigen Fällen werden Daten zwar übertragen, ohne dass ein SQL-Fehler auftritt. Die Daten werden jedoch abgeschnitten, gerundet, oder sind danach unbrauchbar, oder auch verfälscht:

¡        [rtrunc]:  Rechtsbündiges Abschneiden (right truncation)
“Links” oder “rechts” bezieht sich dabei auf die übliche Schreibung eines Wertes. So sind vom rechtsbündigen Abschneiden einer Zahl z.B. nur die Nachkommastellen betroffen.

¡        [ltrunc]: Linksbündiges Abschneiden (left truncation)

¡        [round]: Auf- oder Abrunden einer Zahl durch die Konvertierung.

¡        [0]: Ein “zu kleiner” Wert wird auf 0 gerundet (“underflow”).

¡        [undef]: Das Konvertierungsergebnis ist undefiniert.
Es gibt mehrere mögliche Ergebniswerte. Das konkrete Ergebnis ist entweder gar nicht a priori bekannt, oder nur mit einem für die Praxis unbrauchbar komplexen Satz an Regeln beschreibbar.

¡        [null]: Die Konvertierung liefert den SQL-Wert NULL.

¡        [ok]: Die Konvertierung wird ohne Fehler durchgeführt, jedoch ungeprüft.
Die Ausgangsdaten werden zwar konvertiert, ohne jedoch deren Format zu prüfen. Das Ergebnis kann daher ein für den Ergebnistyp unzulässiger Wert sein, der nicht sinnvoll weiterverarbeitet werden kann. Ein Beispiel wäre ein Datumsfeld, das nach einer Konvertierung eine ungültige Angabe wie “99999999” oder sogar “abcdefgh” enthält.

Eine Kombination von ABAP-Datentyp und Datenbank-Spaltentyp läßt sich in feinere Teilkategorien aufgliedern, hier am Beispiel der Übertragungsrichtung von ABAP zur Datenbank (INSERT, UPDATE):

·        Ist die ABAP-Feldbreite größer als die Datenbank-Spaltenbreite, so kann das ABAP-Feld Werte enthalten, für die in der Datenbankspalte nicht genügend Platz bereitsteht. Dies gibt dann auch die weiteren Teilfälle vor: der konkrete Datenwert in ABAP findet Platz in der DB-Spalte, oder nicht.

·        Ist die ABAP-Feldbreite höchstens so groß wie die Datenbank-Spaltenbreite, so findet ein ABAP-Datenwert immer Platz in der Datenbankspalte.

·        Einige Typen wie zahlenwertige Spalten erwarten Werte in einem bestimmten Format. Dies ist insbesondere in Kombination mit einem zeichenartigen Typ relevant, z.B. beim Schreiben eines ABAP-Zeichenfeldes (Typ c) in eine Integer-Spalte.

Native SQL für Oracle

Native SQL für Informix

Native SQL für DB2 Common Server