Anfang des Inhaltsbereichs

Native SQL Dokument im Navigationsbaum lokalisieren

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 von R/3 entstanden sind.

Ein ABAP-Programm mit datenbankspezifischen SQL-Anweisungen läuft im allgemeinen nicht mit verschiedenen Datenbanken. Falls ein Programm mit verschiedenen Datenbanken 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 muß 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.

Beispiel

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:

Diese Grafik wird im zugehörigen Text erklärt 

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 von R/3: 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 muß wie jedes andere Feld auch behandelt werden.

Native SQL und Transaktionen

Um ein konsistentes Transaktionsverhalten des R/3-Systems 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.

Beispiel

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

Cursorverarbeitung

Die Cursorverarbeitung über Native SQL ähnelt Open SQL:

Beispiel

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

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, daß sich ABAP-Datentyp und Typ der Datenbankspalte direkt entsprechen.

Ist die Datenbanktabelle nicht im ABA PDictionary 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, daß 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 muß davon ausgegangen werden, daß die Beschreibung nur genau für das angegebene Release zutrifft.

Konversionsergebnisse sind in einer Resultatspalte aufgeführt:

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):

Native SQL für Oracle

Native SQL für Informix

Native SQL für DB2 Common Server

Ende des Inhaltsbereichs