Net.Data stellt Sprachumgebungen für relationale Datenbanken bereit, um Ihnen den Zugriff auf Ihre relationalen Datenquellen zu erleichtern. Die SQL-Anweisungen, die Sie für den Zugriff auf die relationalen Daten bereitstellen, werden als dynamisches SQL ausgeführt. Weitere Informationen zu dynamischem SQL finden Sie in Ihrer Datenbankdokumentation.
In den folgenden Abschnitten werden die Sprachumgebungen und ihre Verwendung beschrieben:
Die ODBC-Sprachumgebung (ODBC - Open Database Connectivity) führt SQL-Anweisungen über eine ODBC-Schnittstelle aus. ODBC basiert auf der X/Open SQL CAE-Spezifikation, mit der eine einzelne Anwendung auf viele Datenbankverwaltungssysteme zugreifen kann.
Gehen Sie wie folgt vor, um die ODBC-Sprachumgebung zu verwenden:
Damit Sie die ODBC-Sprachumgebung verwenden können, müssen Sie zuerst einen ODBC-Treiber und einen Treibermanager erwerben und installieren. Informationen zur Installation und Konfiguration der ODBC-Umgebung finden Sie in Ihrer ODBC-Treiberdokumentation.
Prüfen Sie, ob sich eine Konfigurationsanweisung wie die folgende in der Net.Data-Initialisierungsdatei befindet und in einer Zeile steht.
ENVIRONMENT (DTW_ODBC) d:/net.data/lib/dtwodbc.dll ( IN DATABASE, LOGIN, PASSWORD, TRANSACTION_SCOPE, START_ROW_NUM, DTW_SET_TOTAL_ROWS)
Einschränkungen:
Ihre Datenbank hat eventuell andere Begrenzungen. Ermitteln Sie anhand der Dokumentation für Ihre Datenbank, ob Ihre Datenbank eine andere Begrenzung hat.
Die Oracle-Sprachumgebung bietet Basiszugriff auf Ihre Oracle-Daten. Sie können von Net.Data über CGI, FastCGI, NSAPI, ISAPI oder APAPI auf Oracle-Datenbanken zugreifen. Diese Sprachumgebung unterstützt Oracle Version 8.1.5.
Stellen Sie sicher, dass die folgende Konfigurationsanweisung in der Initialisierungsdatei enthalten ist und in einer Zeile steht, damit Sie die Oracle-Sprachumgebung verwenden können.
ENVIRONMENT (DTW_ORA) /net.data/lib/dtwora.so (IN DATABASE, LOGIN, PASSWORD, TRANSACTION_SCOPE, START_ROW_NUM, DTW_SET_TOTAL_ROWS)
Informationen zum weiteren Definieren der Oracle-Sprachumgebung finden Sie in Definieren der Oracle-Sprachumgebung.
Einschränkungen:
LOGIN=admin@ora73
Die SQL-Sprachumgebung bietet Zugriff auf DB2-Datenbanken. Verwenden Sie diese Sprachumgebung für optimale Leistung beim Zugreifen auf DB2.
Stellen Sie sicher, dass die folgende Konfigurationsanweisung in der Initialisierungsdatei enthalten ist und in einer Zeile steht, damit Sie die SQL-Sprachumgebung verwenden können.
ENVIRONMENT (DTW_SQL) d:/net.data/lib/dtwsql.dll (IN DATABASE, LOGIN, PASSWORD, TRANSACTION_SCOPE, START_ROW_NUM, DTW_SET_TOTAL_ROWS)
Verschachtelte SQL-Anweisungen
Sie können SQL-Funktionen innerhalb einer anderen SQL-Funktion aufrufen. Stellen Sie beim Übergeben von Tabellen sicher, dass Sie in jeder Funktion eindeutige Tabellennamen verwenden; andernfalls können unvorhersehbare Ergebnisse auftreten.
Beispiel: Aufrufen einer SQL-Funktion vom ROW-Block einer anderen SQL-Funktion aus
%define mytable1 = %TABLE %define mytable2 = %TABLE %FUNCTION(DTW_SQL) sql2 (IN p1, OUT t2) { select * from NETDATA.STAFFINF where projno='$(p1)' %REPORT { %ROW { $(N1) is $(V1) %} %} %} %FUNCTION(DTW_SQL) sql1 (OUT t1) { select * from NETDATA.STAFFINF %REPORT { %ROW { @sql2(V1, mytable2) %} %} %} %HTML(netcall1) { @sql1(mytable1) %}
Einschränkungen:
Ihre Datenbank hat eventuell andere Begrenzungen. Ermitteln Sie anhand der Dokumentation für Ihre Datenbank, ob Ihr DBMS eine andere Begrenzung hat.
Wenn sie richtig verwendet werden, können Parametermarken die Leistung Ihrer Abfragen verbessern, indem sie DB2 anweisen, den Cache zu verwenden. Eine Parametermarke ist ein Fragezeichen (?) in einer SQL-Anweisung und gibt eine Position an, an der ein von einer Anwendung angegebener Wert ersetzt wird, wenn die Anweisung ausgeführt wird. Der Wert wird aus einer Net.Data-Variable in der Parameterliste der Net.Data-SQL-Funktionsdefinition abgerufen. Die Art und Weise, wie diese Werte abgerufen werden, hängt davon ab, wie Sie Parametermarken verwenden.
Sie können Parametermarken auf die folgenden zwei Arten verwenden:
Explizite Verwendung von Parametermarken:
Wenn Sie eine SQL-Anweisung erstellen, können Sie Ihrer Abfrage wie folgt manuelle Parametermarken hinzufügen:
Beispiel:
%FUNCTION (DTW_SQL) select_staff(in id, in dept){ select * from staff where id = ? and dept = ? and salary = 35,000%}
Für jede Parametermarke gibt es in der Funktion DTW_SQL einen entsprechenden Parameter IN. Die Zuordnungsreihenfolge sowohl für die SQL- als auch für die Funktionsparameterliste ist von links nach rechts. Funktionsparameter, die keiner SQL-Parametermarke zugeordnet sind, können an das Ende der Funktionsparameterliste gestellt werden.
Implizite Verwendung von Parametermarken:
Die implizite Verwendung von Parametermarken wird aktiviert, indem die Markierung DTW_USE_DB2_PREPARE_CACHE = YES in der Initialisierungsdatei oder im Makro angegeben wird. Wenn die Konfigurationsvariable DTW_USE_DB2_PREPARE_CACHE auf YES gesetzt ist, ersetzt Net.Data jede Variable in der SQL-Anweisung durch eine Parametermarke. Die Daten werden an jede Parametermarke gebunden und werden nicht von der Net.Data-Parameterliste übergeben (wie das bei der expliziten Verwendung von Parametermarken der Fall ist).
Beispiel:
%FUNCTION (DTW_SQL) select_staff() { select * from staff where id = $(ID) and dept = $(dept) and salary = 35,000%}
Einschränkungen:
Wenn Sie den Inhalt einer Datenbank mit INSERT-, DELETE- oder UPDATE-Anweisungen ändern, werden diese Änderungen erst festgeschrieben, nachdem die Datenbank eine COMMIT-Anweisung von Net.Data empfangen hat. Wenn ein Fehler auftritt, sendet Net.Data eine ROLLBACK-Anweisung an die Datenbank, die alle Änderungen seit der letzten COMMIT-Operation zurücknimmt.
Wie Net.Data die COMMIT-Anweisung und die etwaige ROLLBACK-Anweisung sendet, hängt davon ab, wie Sie TRANSACTION_SCOPE festlegen und ob COMMIT-Anweisungen explizit im Makro angegeben sind. Zulässige Werte für TRANSACTION_SCOPE sind MULTIPLE und SINGLE. Der Standardwert ist MULTIPLE. Soll SINGLE für TRANSACTION_SCOPE angegeben werden, verwenden Sie eine Anweisung %DEFINE oder einen @DTW_ASSIGN()-Aufruf und übergeben die Variable in der Anweisung ENVIRONMENT für die entsprechende Sprachumgebung. Weitere Informationen finden Sie im Abschnitt zur Anpassung der Net.Data-Initialisierungsdatei in Kapitel 2 dieses Handbuchs.
Gibt an, dass Net.Data nach jeder erfolgreichen SQL-Anweisung eine COMMIT-Anweisung absetzt. Wenn die SQL-Anweisung einen Fehler zurückgibt, wird eine ROLLBACK-Anweisung abgesetzt. Die Angabe SINGLE für TRANSACTION_SCOPE stellt eine sofortige Datenbankänderung sicher. Allerdings kann eine Änderung später mit Hilfe einer ROLLBACK-Anweisung nicht widerrufen werden.
Gibt an, dass Net.Data alle SQL-Anweisungen vor dem Absetzen einer COMMIT-Anweisung ausführt. Net.Data sendet die COMMIT-Anweisung am Ende der Anforderung, und wenn jede SQL-Anweisung erfolgreich abgesetzt wird, schreibt die COMMIT-Anweisung alle Änderungen in der Datenbank fest. Wenn durch eine der Anweisungen ein Fehler zurückgegeben wird, setzt Net.Data eine ROLLBACK-Anweisung am Fehlerpunkt ab, die die Datenbank auf ihren vorherigen Status zurücksetzt.
Wenn Sie als Anwendungsentwickler die Standardeinstellung MULTIPLE für TRANSACTION_SCOPE beibehalten und wenn Sie COMMIT-Anweisungen am Ende der Anweisungsgruppen absetzen, die als Transaktion in Frage kommen, haben Sie volle Kontrolle über das COMMIT- und ROLLBACK-Verhalten in Ihrer Anwendung. Zum Beispiel kann das Absetzen von COMMIT-Anweisungen nach jeder Aktualisierung in Ihrem Makro zur Integritätsbewahrung Ihrer Daten beitragen.
Zum Absetzen einer SQL-Anweisung COMMIT können Sie eine Funktion definieren, die Sie an einem beliebigen Punkt in Ihrem HTML-Block aufrufen können:
%FUNCTION(DTW_SQL) user_commit() { commit %} ... %HTML { ... @user_commit() ... %}
Einschränkungen:
Die Einstellung von TRANSACTION_SCOPE kann nicht mehr geändert werden, nachdem eine Verbindung zur Datenbank hergestellt wurde. Deshalb unterliegen alle SQL-Transaktionen in einem Makro derselben Verarbeitung.
Wenn Sie Net.Data als Teil von Net.Commerce verwenden, beachten Sie, dass Net.Commerce über eine eigene Transaktionsverarbeitung verfügt und die Transaktionsverarbeitung von Net.Data inaktiviert.
Sie können LOB-Dateien (Large Object) in DB2-Datenbanken speichern und mit der SQL- oder ODBC-Sprachumgebung von Net.Data in Ihre Webanwendungen einbinden.
Wenn die Sprachumgebung eine SQL-Anweisung SELECT oder eine gespeicherte Prozedur ausführt, die ein LOB zurückgibt, wird das Objekt weder einer Variablen zur Tabellenverarbeitung V(n) noch einem Net.Data-Tabellenfeld zugeordnet. Stattdessen wird das LOB in einer Datei gespeichert, die Net.Data erstellt, und nur der Name der Datei wird in der Variablen zur Tabellenverarbeitung V(n) oder in einem Net.Data-Tabellenfeld zurückgegeben. In Ihrem Net.Data-Makro können Sie den Namen verwenden, um auf die LOB-Datei zu verweisen; Sie können z. B. ein HTML-Ankerelement mit einem Hypertext-Verweis oder ein Bildelement, das eine URL für die Datei enthält, verwenden. Net.Data stellt die Datei mit dem LOB in das durch die Konfigurationsvariable HTML_PATH angegebene Verzeichnis. Diese Pfadanweisung befindet sich in der Net.Data-Initialisierungsdatei (db2www.ini). Der Schreibzugriff auf die LOB-Datei ist auf die Benutzer-ID beschränkt, die der Net.Data-Anforderung zugeordnet ist, mit der das LOB abgerufen wurde.
Der Dateiname für das LOB wird dynamisch erstellt und weist folgendes Format auf:
name[.extension]
Dabei gilt Folgendes:
Tabelle 8. In der SQL-Sprachumgebung verwendete LOB-Erweiterungen
Erweiterung | Objekttyp |
---|---|
.bmp | Bitmap-Image |
.gif | Graphical Image Format |
.jpg | JPEG-Image (Joint Photographic Experts Group) |
.tif | Tagged Image File Format |
.ps | PostScript |
.mid | MIDI-Audio |
.aif | AIFF-Audio |
.avi | AVI |
.au | Basisaudio |
.ra | RA |
.wav | WAV |
Portable Document Format | |
.rmi | MIDI-Sequenz |
Wird der Objekttyp des binären großen Objekts (BLOB) nicht erkannt, wird dem Dateinamen keine Erweiterung hinzugefügt.
Wenn Net.Data den Namen der Datei zurückgibt, die ein LOB enthält, erhält der Dateiname das Präfix /tmplobs/ unter Verwendung der folgenden Syntax:
/tmplobs/name.[extension]
Mit Hilfe dieses Präfix können Sie Ihr LOB-Verzeichnis in einem anderen Verzeichnis als dem Stammverzeichnis des Webservers anlegen.
Fügen Sie der Konfigurationsdatei Ihres Webservers die folgende Pass-Anweisung hinzu, um sicherzustellen, dass Verweise auf LOB-Dateien richtig aufgelöst werden:
Pass /tmplobs/* <full_path>/tmplobs/*
<full_path> ist der Wert, der für die Konfigurationsvariable HTML_PATH in der Net.Data-Initialisierungsdatei angegeben wurde.
Hinweis zur Planung: Jede Abfrage, die LOBs zurückgibt, führt zur Erstellung von Dateien in dem durch die Pfadkonfigurationsvariable HTML_PATH angegebenen Verzeichnis. Bei der Verwendung von LOBs ist die jeweilige Systemausstattung zu berücksichtigen, da diese Objekte die Systemressourcen schnell aufbrauchen können. Bereinigen Sie das Verzeichnis regelmäßig, oder führen Sie den Dämon dtwclean aus. Weitere Informationen hierzu finden Sie in Verwalten temporärer LOBs. Es wird empfohlen, DataLinks zu verwenden. Dadurch braucht die SQL-Sprachumgebung Dateien nicht mehr in Verzeichnissen zu speichern, was zu einer Leistungsoptimierung und einer wesentlichen Reduzierung der belegten Systemressourcen führt.
Beispiel: Die folgende Anwendung verwendet eine MPEG-Audiodatei (.mpa). Da die SQL-Sprachumgebung diesen Dateityp nicht erkennt, wird eine EXEC-Variable dazu verwendet, die Erweiterung .mpa an den Dateinamen anzuhängen. Ein Benutzer dieser Anwendung muss den Dateinamen anklicken, um die Anzeigefunktion für MPEG-Audiodateien aufzurufen.
%DEFINE{ lobdir="/u/IBMUSER/tmplobs"" myFile=%EXEC "rename $(lobdir)$(filename) $(lobdir)$(filename).mpa" %} %{ where rename is the command on your operating system to rename files %} %FUNCTION(DTW_SQL) queryData() { SELECT Name, IDPhoto, Voice FROM RepProfile %REPORT{ <p>Here is the information you selected:</p> %ROW{ @DTW_ASSIGN(filename, @DTW_rSUBSTR(V3, @DTW_rLASTPOS("/", V3))) $(myFile) $(V1) <img src="$(V2)"> <a href="$(V3).mpa">Voice sample</a><p> %} %} %} %HTML (Report){ @queryData() %}
Wenn die Tabelle RepProfile Informationen zu Kinson Yamamoto und Merilee Lau enthält, wird der Webseite, die generiert wird, bei der Ausführung des REPORT-Blocks der folgende HTML-Text hinzugefügt:
<p>Here is the information you selected:</p> Kinson Yamamoto <img src="/tmplobs/p2345n1.gif"> <a href="/tmplobs/p2345n2.mpa">Voice sample</a><p> Merilee Lau <img src="/tmplobs/p2345n3.gif"> <a href="/tmplobs/p2345n4.mpa">Voice sample</a><p>
Der REPORT-Block im vorangegangenen Beispiel verwendet die impliziten Tabellenvariablen V1, V2 und V3.
Zugriffsrechte für LOBs:
Das Standardverzeichnis tmplobs für LOBs ist unter dem Verzeichnis angeordnet, das durch HTML_PATH in der mitgelieferten Net.Data-Initialisierungsdatei angegeben ist. Eine beliebige Benutzer-ID kann darauf zugreifen. Wenn der Wert von HTML_PATH geändert wird, stellen Sie sicher, dass die Benutzer-ID, unter der der Webserver ausgeführt wird, Schreibzugriff für das durch HTML_PATH angegebene Verzeichnis hat. (Weitere Informationen finden Sie in HTML_PATH.)
Verwalten temporärer LOBs:
Net.Data speichert temporäre LOBs im Unterverzeichnis tmplobs des Verzeichnisses, das in der Pfadkonfigurationsvariablen HTML_PATH angegeben ist. Diese Dateien können groß sein und sollten regelmäßig bereinigt werden, um eine Leistungseinbuße zu vermeiden.
Net.Data stellt den Dämon dtwclean zum periodischen Verwalten des Verzeichnisses tmplobs bereit. dtwclean verwendet den Anschluss 7127.
Gehen Sie wie folgt vor, um den Dämon dtwclean auszuführen: Geben Sie den folgenden Befehl im Befehlszeilenfenster ein:
dtwclean [-t xx] [-d|-l]
Dabei gilt Folgendes:
Eine gespeicherte Prozedur ist ein kompiliertes Programm, das in einer Datenbank gespeichert ist und SQL-Anweisungen ausführen kann. In Net.Data werden gespeicherte Prozeduren von Net.Data-Funktionen mit Hilfe der Anweisung CALL aufgerufen. Parameter für gespeicherte Prozeduren werden aus der Parameterliste der Net.Data-Funktion übergeben. Sie können gespeicherte Prozeduren einsetzen, um die Leistung und die Integrität zu verbessern, indem Sie kompilierte SQL-Anweisungen auf dem Datenbankserver speichern. Net.Data unterstützt die Verwendung gespeicherter Prozeduren unter DB2 über die SQL- und ODBC-Sprachumgebungen. Gespeicherte Prozeduren von Oracle werden über die Oracle-Sprachumgebung unterstützt. Net.Data unterstützt insbesondere für DB2 gespeicherte Prozeduren, die mindestens eine Ergebnismenge zurückgeben.
In diesem Abschnitt werden folgende Themen behandelt:
Die Syntax für gespeicherte Prozeduren enthält die Anweisung FUNCTION, die Anweisung CALL und optional einen REPORT-Block.
%FUNCTION (DTW_SQL) function_name ([IN datatype arg1, INOUT datatype arg2, OUT resultsetname, ...]) { CALL stored_procedure [(resultsetname, ...)] [%REPORT [(resultsetname)] { %}] ... [%REPORT [(resultsetname)] { %}] [%MESSAGE %}] %}
Dabei gilt Folgendes:
Tabelle 9. Unterstützte Datentypen gespeicherter Prozeduren für DB2
BIGINT | DOUBLEPRECISION | SMALLINT |
CHAR | FLOAT | TIME |
CLOB1 | INTEGER | TIMESTAMP |
DATE | GRAPHIC | VARCHAR |
DECIMAL | LONGVARCHAR | VARGRAPHIC |
DOUBLE | LONGVARGRAPHIC |
|
1 CLOB kann nur als Parameter für OUT und INOUT verwendet werden, und Net.Data interpretiert die Größe in Byte. Wenn Sie z. B. eine Variable OUT CLOB(20000) angeben, wird ein CLOB der Größe 20 K als Ausgabeparameter verwendet. |
Tabelle 10. Unterstützte Datentypen gespeicherter Prozeduren für Oracle
BIGINT | LONG |
CHAR | LONG RAW |
DATE | NUMBER |
DECIMAL | RAW |
FLOAT | VARCHAR / VACHAR2 |
INTEGER |
|
%FUNCTION (DTW_SQL) function_name()
%FUNCTION (DTW_SQL) function_name (IN datatype arg1, INOUT datatype arg2, OUT resultsetname...)
CALL stored_procedure
%REPORT [(resultsetname)] { ... %}
Beispiel:
%FUNCTION (DTW_SQL) mystoredproc (IN CHAR(30) arg1) { CALL myproc %REPORT (mytable){ ... %ROW { ... %} ... %} %}
CALL stored_procedure[ (resultsetname1[, resultsetname2, ...]) ]
%REPORT[(resultsetname1)] { ... %}
Beispiel:
%FUNCTION (DTW_SQL) mystoredproc (IN CHAR(30) arg1, OUT table1) { CALL myproc (table1, table2) %REPORT(table2) { ... %ROW { ... %} ... %} %}
Beispiel:
%FUNCTION (DTW_ORA) orastp (IN datatype arg1, OUT datatype arg2,...) returns (DTWORA_RESULT) { CALL stored_oracle_function %}
Sie können Parameter an eine gespeicherte Prozedur übergeben und die gespeicherte Prozedur die Parameterwerte aktualisieren lassen, so dass die neuen Werte an das Net.Data-Makro zurückgegeben werden. Die Anzahl und der Typ der Parameter in der Funktionsparameterliste müssen mit der Anzahl und dem Typ übereinstimmen, die für die gespeicherte Prozedur definiert sind. Wenn z. B. ein Parameter in der für die gespeicherte Prozedur definierten Parameterliste INOUT ist, dann muss der entsprechende Parameter in der Funktionsparameterliste auch INOUT sein. Wenn ein Parameter in der für die gespeicherte Prozedur definierten Parameterliste vom Typ CHAR(30) ist, dann muss der entsprechende Parameter in der Funktionsparameterliste auch CHAR(30) sein.
Beispiel 1: Übergeben eines Parameterwerts an die gespeicherte Prozedur
%FUNCTION (DTW_SQL) mystoredproc (IN CHAR(30) valuein) { CALL myproc ...
Beispiel 2: Zurückgeben eines Werts aus einer gespeicherten Prozedur
%FUNCTION (DTW_SQL) mystoredproc (OUT VARCHAR(9) retvalue) { CALL myproc ...
Sie können mindestens eine Ergebnismenge aus einer gespeicherten Prozedur zurückgeben, wenn Sie die SQL- oder ODBC-Sprachumgebung verwenden. Die Ergebnismengen können in Net.Data-Tabellen zur weiteren Verarbeitung innerhalb Ihres Makros gespeichert oder mit Hilfe eines REPORT-Blocks verarbeitet werden. Wenn eine gespeicherte Prozedur mehrere Ergebnismengen generiert, müssen Sie jeder durch die gespeicherte Prozedur generierten Ergebnismenge einen Namen zuordnen. Dies geschieht durch die Angabe von Parametern in der Anweisung CALL. Der Name, den Sie für eine Ergebnismenge angeben, kann anschließend einem REPORT-Block oder einer Net.Data-Tabelle zugeordnet werden, so dass Sie festlegen können, wie die einzelnen Ergebnismengen von Net.Data verarbeitet werden. Sie haben folgende Möglichkeiten:
Richtlinien und Einschränkungen zur Verwendung mehrerer REPORT-Blöcke finden Sie in Richtlinien und Einschränkungen für mehrere REPORT-Blöcke.
Gehen Sie wie folgt vor, wenn nur eine Ergebnismenge zurückgegeben und diese in einem Standardbericht angezeigt werden soll:
Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name () { CALL stored_procedure %}
Beispiel:
%FUNCTION (DTW_SQL) mystoredproc() { CALL myproc %}
Gehen Sie wie folgt vor, wenn nur eine Ergebnismenge zurückgegeben und ein REPORT-Block angegeben werden soll:
Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name () { CALL stored_procedure [(resultsetname)] %REPORT [(resultsetname)] { ... %} %}Beispiel 1:
%FUNCTION (DTW_SQL) mystoredproc () { CALL myproc %REPORT { ... %ROW { ... %} ... %} %}
Beispiel 2:
%FUNCTION (DTW_SQL) mystoredproc () { CALL myproc (mytable1) %REPORT (mytable1) { ... %ROW { ... %} ... %} %}
Gehen Sie wie folgt vor, wenn nur eine Ergebnismenge in einer Net.Data-Tabelle zur weiteren Verarbeitung gespeichert werden soll:
Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name (OUT tablename) { CALL stored_procedure [(resultsetname)] %}
Beispiel:
%DEFINE DTW_DEFAULT_REPORT = "NO" %FUNCTION (DTW_SQL) mystoredproc (OUT mytable1) { CALL myproc %}
Beachten Sie, dass die Variable DTW_DEFAULT_REPORT auf den Wert NO gesetzt ist, so dass kein Standardbericht für die Ergebnismenge generiert wird.
Gehen Sie wie folgt vor, wenn mehrere Ergebnismengen zurückgegeben und diese im Standardberichtsformat angezeigt werden sollen:
Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name () { CALL stored_procedure [(resultsetname1, resultsetname2, ...)] %}
Dabei wird kein REPORT-Block angegeben.
Beispiel:
%DEFINE DTW_DEFAULT_REPORT = "YES" %FUNCTION (DTW_SQL) mystoredproc () { CALL myproc %}
Gehen Sie wie folgt vor, wenn mehrere Ergebnismengen zurückgegeben und die Ergebnismengen in Net.Data-Tabellen zur weiteren Verarbeitung gespeichert werden sollen:
Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name (OUT (resultsetname1, resultsetname2, ...) { CALL stored_procedure (resultsetname1, resultsetname2, ...) %}
Beispiel:
%DEFINE DTW_DEFAULT_REPORT = "NO" %FUNCTION (DTW_SQL) mystoredproc (OUT mytable1, mytable2) { CALL myproc (mytable1, mytable2) %}
Beachten Sie, dass die Variable DTW_DEFAULT_REPORT auf den Wert NO gesetzt ist, so dass kein Standardbericht für die Ergebnismengen generiert wird.
Gehen Sie wie folgt vor, wenn mehrere Ergebnismengen zurückgegeben und REPORT-Blöcke für die Verarbeitung der Anzeige angegeben werden sollen:
Jede Ergebnismenge ist einem REPORT-Block oder mehreren REPORT-Blöcken zugeordnet. Verwenden Sie die folgende Syntax:
%FUNCTION (DTW_SQL) function_name (, ...) { CALL stored_procedure (resultsetname1, resultsetname2, ...) %REPORT (resultsetname1) ... %ROW { ... %} ... %} %REPORT (resultsetname2) ... %ROW { ... %} ... %} ... %}
Beispiel:
%FUNCTION (DTW_SQL) mystoredproc () { CALL myproc (mytable1, mytable2) %REPORT (mytable1) { ... %ROW { ... %} ... %} %REPORT(mytable2) { ... %ROW { ... %} ... %} %}
Gehen Sie wie folgt vor, wenn mehrere Ergebnismengen zurückgegeben und für jede Ergebnismenge verschiedene Anzeige- oder Verarbeitungsoptionen angegeben werden sollen:
Sie können für jede Ergebnismenge andere Verarbeitungsoptionen angeben, indem Sie eindeutige Parameternamen verwenden. Beispiel 1:
%FUNCTION (DTW_SQL) mystoredproc (OUT mytable2) { CALL myproc (mytable1, mytable2, mytable3) %REPORT (mytable1) { ... %ROW { ... %} ... %} %}Die Ergebnismenge mytable1 wird vom entsprechenden REPORT-Block verarbeitet und wie vom Makroautor angegeben angezeigt. Die Ergebnismenge mytable2 wird in der Net.Data-Tabelle mytable2 gespeichert und kann nun zur weiteren Verarbeitung, zum Beispiel zur Übergabe an eine andere Funktion, verwendet werden. Die Ergebnismenge mytable3 wird im Standardberichtsformat von Net.Data angezeigt, weil für sie kein REPORT-Block angegeben wurde.
Beispiel 2:
%FUNCTION(DTW_SQL) mystoredproc(OUT mytable4, OUT mytable3) { CALL myproc (mytable1, mytable2, mytable3, mytable4) %REPORT(mytable2) { ... %ROW { ... %} ... %} %REPORT (mytable1) { ... %ROW { ... %} ... %} %REPORT(mytable4) { ... %ROW { ... %} ... %} %}
Die Ergebnismengen mytable2, mytable1 und mytable4 werden durch den entsprechenden REPORT-Block in dieser Reihenfolge verarbeitet und wie angegeben angezeigt. Die Ergebnismengen mytable4 und mytable3 werden zur weiteren Verarbeitung in Tabellenvariablen gespeichert. Die Ergebnismenge mytable3 wird auch mit Hilfe des Net.Data-Standardberichtsformats angezeigt, sobald die Verarbeitung der drei REPORT-Blöcke abgeschlossen ist.
Der Datentyp DATALINK ist einer der Grundbausteine für die Erweiterung der Datentypen, die in Datenbankdateien gespeichert werden können. Bei DATALINK sind die in der Spalte gespeicherten Daten lediglich ein Zeiger zur Datei. Diese Datei kann in einem beliebigen Dateityp vorliegen, z. B. eine Abbilddatei, eine Stimmaufzeichnung oder eine Textdatei. DataLink-Datentypen speichern eine URL-Adresse, um die Speicherposition der Datei aufzulösen.
Für den Datentyp DATALINK ist die Verwendung von DataLink File Manager erforderlich. Weitere Informationen zu DataLink File Manager finden Sie in der DataLinks-Dokumentation für Ihr Betriebssystem. Vor der Verwendung des Datentyps DATALINK müssen Sie sicherstellen, dass der Webserver Zugriff auf das durch den Server mit DB2 File Manager verwaltete Dateisystem hat.
Wenn eine SQL-Abfrage eine Ergebnismenge mit DataLinks zurückgibt und die DataLink-Spalte mit den DataLink-Optionen FILE LINK CONTROL und READ PERMISSION DB erstellt wird, enthalten die Dateipfade in der DataLink-Spalte ein Zugriffs-Token. DB2 überprüft mit dem Zugriffs-Token den Zugriff auf die Datei. Ohne dieses Zugriffs-Token schlagen alle Zugriffsversuche auf die Datei mit einer Berechtigungsverletzung fehl. Das Zugriffs-Token enthält jedoch unter Umständen Zeichen, die in einer URL-Adresse (die an einen Browser zurückgegeben werden soll) nicht verwendet werden können, z. B. das Semikolon (;). Beispiel:
/datalink/pics/UN1B;0YPVKGG346KEBE;baibien.jpg
Die URL-Adresse ist ungültig, weil sie Semikolons (;) enthält. Die Semikolons müssen mit der integrierten Net.Data-Funktion DTW_URLESCSEQ codiert werden, um die Ungültigkeit der URL-Adresse aufzuheben. Vor der Anwendung dieser Funktion muss die Zeichenfolge allerdings noch bearbeitet werden, weil diese Funktion auch Schrägstriche (/) codiert.
Sie können eine Net.Data-Makrofunktion (MACRO_FUNCTION) schreiben, um die Bearbeitung der Zeichenfolge zu automatisieren und die Funktion DTW_URLESCSEQ zu verwenden. Verwenden Sie dieses Verfahren in jedem Makro, das Daten aus einer Spalte mit dem Datentyp DATALINK abruft.
Beispiel 1: MACRO_FUNCTION zur Automatisierung der Codierung von URL-Adressen, die von DB2 UDB zurückgegeben werden
%{ TO DO: Apply DTW_URLESCSEQ to a DATALINK URL to make it a valid URL. IN: DATALINK URL from DB2 File Manager column. RETURN: The URL with token portion is URL encoded %} %MACRO_FUNCTION encodeDataLink(in DLURL) { @DTW_rCONCAT( @DTW_rDELSTR( DLURL, @DTW_rADD(@DTW_rLASTPOS("/", DLURL), "1" ) ), @DTW_rURLESCSEQ( @DTW_rSUBSTR(DLURL, @DTW_rADD( @DTW_rLASTPOS("/", DLURL), "1" ) ) ) ) %}
Nach der Verwendung dieser Makrofunktion ist die URL-Adresse ordnungsgemäß codiert, und auf die in der Spalte DATALINK angegebene Datei kann in einem beliebigen Web-Browser verwiesen werden.
Beispiel 2: Ein Net.Data-Makro zur Angabe der SQL-Abfrage, die die DATALINK-URL-Adresse zurückgibt
%FUNCTION(DTW_SQL) myQuery(){ select name, DLURLCOMPLETE(picture) from myTable where name like '%river%' %REPORT{ %ROW{ <p> $(V1) <br /> Before Encoding: $(V2) <br /> After Encoding: @encodeDataLInk($(V2)) <br /> Make HREF: <a href="@encodeDataLink($(V2))"> click here </a> <br /> <p> %} %} %}
Beachten Sie, dass eine Funktion von DataLink File Manager verwendet wird. Die Funktion dlurlcomplete gibt eine vollständige URL-Adresse zurück.
Die folgenden Beispiele zeigen, wie Sie die Sprachumgebung für relationalen Datenbanken von Ihren Makros aus aufrufen können:
Das folgende Beispiel definiert und ruft Mehrfachfunktionen für die ODBC-Sprachumgebung auf.
%DEFINE { DATABASE="qesq1" SHOWSQL="YES" table="int_null" LOGIN="netdata1" PASSWORD="ibmdb2"%} %function(dtw_odbc) sq1() { create table int_null (int1 int, int2 int) %} %function(dtw_odbc) sql2() { insert into $(table) (int1) values (111) %} %function(dtw_odbc) sql3() { insert into $(table) (int2) values (222) %} %function(dtw_odbc) sql4() { select * from $(table) %} %function(dtw_odbc) sql5() { drop table $(table) %} %HTML(REPORT){ @sql1() @sql2() @sql3() @sql4() %}
%DEFINE { LOGIN="ulogin" PASSWORD="upassword" DATABASE="" table= "utable" %} %FUNCTION(DTW_ORA) myQuery(){ select ename,job,empno,hiredate,sal,deptno from $(table) order by ename %} %MESSAGE{ 100 : "<b>WARNING</b>: No employee were found that met your search criteria.<p>" : continue %} %HTML(REPORT){ @myQuery() %}
Das folgende Beispiel zeigt ein Makro mit einer DTW_SQL-Funktionsdefinition, die eine gespeicherte SQL-Prozedur aufruft. Darin sind drei Parameter mit unterschiedlichen Datentypen enthalten. Die Sprachumgebung DTW_SQL übergibt jeden Parameter in Übereinstimmung mit dem Datentyp des Parameters an die gespeicherte Prozedur. Wenn die Verarbeitung der gespeicherten Prozedur abgeschlossen ist, werden Ausgabeparameter zurückgegeben, und Net.Data aktualisiert die Variablen entsprechend.
%{*********************************************************** DEFINE BLOCK ************************************************************%} %DEFINE { MACRO_NAME = "TEST ALL TYPES" DTW_HTML_TABLE = "YES" parm1 = "1" %{SMALLINT %} parm2 = "11" %{INT %} parm3 = "1.1" %{DECIMAL (2,1) %} %} %FUNCTION(DTW_SQL) myProc (INOUT SMALLINT parm1, INOUT INT parm2, INOUT DECIMAL(2,1) parm3){ CALL TESTTYPE %} %HTML(report){ <head> <title>Net.Data : SQL Stored Procedure: Example '$(MACRO_NAME)'. </title> </head> <body bgcolor="#bbffff" text="#000000" link="#000000"> <p> Calling the function to create the stored procedure. <p></p> @CRTPROC() <hr/> <h2> Values of the INOUT parameters prior to calling the stored procedure: </h2> <b>parm1 (SMALLINT)<p></b> $(parm1)<br /> <b>parm2 (INT)</b> $(parm2)<br /> <b>parm3 (DECIMAL)</b> $(parm3) <hr/> <h2> Calling the function that executes the stored procedure. </h2> <p> @myProc(parm1,parm2,parm3) </p><hr/> <h2> Values of the INOUT parameters after calling the stored procedure:<p> </h2> <p><b>parm1 (SMALLINT)</b><br /> $(parm1)<br /> <b>parm2 (INT)</b> $(parm2)<br /> <b>parm3 (DECIMAL)</b> $(parm3) </p></body> %}