Verwaltung und Programmierung

Sprachumgebungen für relationale Datenbanken

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:

ODBC-Sprachumgebung

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.

Anmerkung:
Der Pfad in dem folgenden Beispiel kann je nach Ihrem Betriebssystem abweichen.
ENVIRONMENT
(DTW_ODBC) d:/net.data/lib/dtwodbc.dll ( IN DATABASE, LOGIN, PASSWORD,
  TRANSACTION_SCOPE, START_ROW_NUM, DTW_SET_TOTAL_ROWS)

Einschränkungen:

Oracle-Sprachumgebung

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.

Anmerkung:
Der Pfad in dieser Konfigurationsanweisung kann je nach Ihrem Betriebssystem oder Ihrer Installation abweichen.
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:

SQL-Sprachumgebung

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.

Anmerkung:
Der Pfad in dieser Konfigurationsanweisung kann je nach Ihrem Betriebssystem oder Ihrer Installation abweichen.
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:

Verwenden von DB2-Parametermarken

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:

Verwalten von Transaktionen in einer Net.Data-Anwendung

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.

SINGLE

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.

MULTIPLE

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.

Verwenden großer Objekte

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:

name
Dies ist eine dynamisch generierte eindeutige Zeichenfolge, die das große Objekt angibt.

extension
Dies ist eine Zeichenfolge, die den Objekttyp angibt. Bei CLOBs und DBCLOBs ist die Erweiterung .txt. Bei BLOBs ermittelt die SQL-Sprachumgebung die Erweiterung, indem sie in den ersten Bytes der LOB-Datei nach einer Kennung sucht. Tabelle 8 zeigt die LOB-Erweiterungen, die die SQL-Sprachumgebung verwendet:

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
.pdf 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:

-t
Diese Markierung gibt das Intervall an, in dem dtwclean das Verzeichnis bereinigt.

xx
Dieses Intervall gibt die Sekunden an, die eine Datei im Verzeichnis verbleibt, bevor dtwclean sie löscht. Für diesen Wert gibt es keine Begrenzung. Der Standardwert ist 3600 Sekunden.

-d
Diese Markierung gibt den Debug-Modus an. Im Befehlsfenster werden Trace-Informationen angezeigt.

-l
Diese Markierung gibt den Protokollierungsmodus an. Trace-Informationen werden in eine Protokolldatei ausgegeben.

Gespeicherte Prozeduren

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:

Syntax für gespeicherte Prozeduren

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:

function_name
Ist der Name der Net.Data-Funktion, die den Aufruf der gespeicherten Prozedur initialisiert.

stored_procedure
Ist der Name der gespeicherten Prozedur.

datatype
Ist einer der von Net.Data unterstützten Datentypen der Datenbank wie in Tabelle 9 und Tabelle 10 gezeigt. Die in der Parameterliste angegebenen Datentypen müssen mit den Datentypen in der gespeicherten Prozedur übereinstimmen. Weitere Informationen zu diesen Datentypen finden Sie in Ihrer Datenbankdokumentation.

Nur für DB2: tablename
Ist der Name der Net.Data-Tabelle, in der die Ergebnismenge gespeichert werden soll (wird nur verwendet, wenn die Ergebnismenge in einer Net.Data-Tabelle gespeichert werden soll). Wenn dieser Parametername angegeben ist, muss er mit dem zugehörigen Parameternamen für resultsetname übereinstimmen.

Nur für DB2: resultsetname
Ist der Name, der eine von einer gespeicherten Prozedur zurückgegebene Ergebnismenge einem REPORT-Block und/oder einem Tabellennamen in der Funktionsparameterliste zuordnet. Die Angabe resultsetname in einem REPORT-Block muss mit einer Ergebnismenge in der Anweisung CALL übereinstimmen.

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

Wichtig:
Wenn Net.Data unter Windows oder Unix eine gespeicherte Prozedur in DB2 unter OS/390 und OS/400 aufruft, muss die gespeicherte Prozedur unter diesen Betriebssystemen den Host-Variablentyp DOUBLE oder FLOAT verwenden, wenn DECIMAL-Daten aus der DB2-Datenbank abgerufen werden. Durch Verwendung des Host-Variablentyps DOUBLE oder FLOAT wird sichergestellt, dass die zurückgegebenen Daten ein lesbares Format aufweisen.

Aufrufen einer gespeicherten Prozedur

  1. Definieren Sie eine Funktion, die einen Aufruf an die gespeicherte Prozedur initialisiert.
    %FUNCTION (DTW_SQL) function_name() 
    
  2. (Optional) Geben Sie beliebige Parameter IN, INOUT oder OUT für die gespeicherte Prozedur an. Bei gespeicherten DB2-Prozeduren kann der Parameter einen Tabellenvariablennamen für die Speicherung einer Ergebnismenge in einer Net.Data-Tabelle enthalten (Sie müssen eine Net.Data-Tabelle nur angeben, wenn die Ergebnismenge in einer Net.Data-Tabelle gespeichert werden soll).
    %FUNCTION (DTW_SQL) function_name (IN datatype
    arg1, INOUT datatype arg2, 
        OUT resultsetname...) 
    
  3. Geben Sie mit Hilfe der Anweisung CALL den Namen der gespeicherten Prozedur an.
     CALL stored_procedure
    
  4. Für DB2: Wenn die gespeicherte DB2-Prozedur nur eine Ergebnismenge generiert, können Sie optional einen REPORT-Block angeben, um zu definieren, wie Net.Data die Ergebnismenge anzeigen soll.
    %REPORT [(resultsetname)] {
    ...
    %}
    

    Beispiel:

    %FUNCTION (DTW_SQL) mystoredproc (IN CHAR(30) arg1)  {
         CALL  myproc
     %REPORT (mytable){
      ...
      %ROW {  ...   %}      
      ...   
     %} 
    %}
    
  5. Wenn die gespeicherte Prozedur mehrere Ergebnismengen generiert, haben Sie folgende Möglichkeiten:
  6. Neben gespeicherten Prozeduren stellt Oracle außerdem gespeicherte Funktionen zur Verfügung. Zum Aufrufen einer gespeicherten Oracle-Funktion muss die Net.Data-Variable DTWORA_RESULT verwendet werden. Nach der Ausführung enthält DTWORA_RESULT den Rückgabewert der gespeicherten Funktion.

    Beispiel:

    %FUNCTION (DTW_ORA) orastp (IN datatype arg1, OUT datatype arg2,...) 
       returns (DTWORA_RESULT) {
       CALL stored_oracle_function
       %}
    

Übergeben von Parametern

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

Verarbeiten von Ergebnismengen aus gespeicherten DB2-Prozeduren

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.

Codieren von DataLink-URL-Adressen in Ergebnismengen

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.

Beispiele für die Sprachumgebung für relationale Datenbanken

Die folgenden Beispiele zeigen, wie Sie die Sprachumgebung für relationalen Datenbanken von Ihren Makros aus aufrufen können:

ODBC

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()
%}

Oracle
Das folgende Beispiel zeigt ein Makro mit einer Funktionsdefinition DTW_ORA, die die Oracle-Datenbank udatabase abfragt. Dabei wird mit einem Variablenverweis die abzufragende Datenbanktabelle ermittelt. Der FUNCTION-Block enthält auch einen MESSAGE-Block, der Fehlerbedingungen behandelt. Net.Data zeigt nach der Verarbeitung des Makros im Browser einen Standardbericht an.
%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()
%}
 
 
 

SQL

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>
%}


[ Seitenanfang | Vorherige Seite | Nächste Seite ]