DB2 Connect Benutzerhandbuch

Programmierung in einer verteilten Umgebung

Mit DB2 Connect können Anwendungsprogramme auf Daten in DB2-Datenbanken auf System/390- und AS/400-Servern zugreifen. Beispielsweise kann eine Anwendung, die unter Windows ausgeführt wird, auf Daten in einer DB2 Universal Database für OS/390-Datenbank zugreifen. Sie können neue Anwendungen erstellen oder bestehende Anwendungen so ändern, daß sie in einer Host- oder AS/400-Umgebung ausgeführt werden können. Sie haben auch die Möglichkeit, Anwendungen in einer Umgebung zu entwickeln und sie dann in eine andere Umgebung zu übertragen.

DB2 Connect ermöglicht Ihnen die Verwendung der folgenden Anwendungsprogrammierschnittstellen (APIs) mit Host-Datenbankprodukten wie beispielsweise DB2 Universal Database für OS/390, sofern die entsprechende Komponente vom Host-Datenbankprodukt unterstützt wird:

Einige SQL-Anweisungen weisen je nach der verwendeten relationalen Datenbank Unterschiede auf. Es gibt SQL-Anweisungen, die:

Die SQL-Anweisungen der ersten beiden Kategorien sind in hohem Maße übertragbar, während für die Anweisungen der dritten Kategorie zunächst Änderungen erforderlich sind. Im allgemeinen gilt, daß SQL-Anweisungen in der Datendefinitionssprache (Data Definition Language, DDL) nicht so einfach übertragbar sind wie diejenigen in der Datenbearbeitungssprache (Data Manipulation Language, DML).

DB2 Connect akzeptiert einige SQL-Anweisungen, die von DB2 Universal Database nicht unterstützt werden. DB2 Connect übergibt diese Anweisungen an den Host- oder AS/400-Server. Das Handbuch SQL Reference enthält Informationen über die für verschiedene Plattformen geltenden Beschränkungen wie beispielsweise die maximale Spaltenlänge.

Wenn Sie eine CICS-Anwendung von OS/390 oder VSE übertragen, um sie unter einem anderen CICS-Produkt (beispielsweise CICS für AIX) ausführen zu lassen, kann diese Anwendung über DB2 Connect auch auf die OS/390- bzw. VSE-Datenbank zugreifen. Die Handbücher CICS/6000 Application Programming Guide und CICS Customization and Operation enthalten weitere Informationen.

Wenn Sie in einer Host- oder AS/400-Umgebung programmieren, sollten Sie die folgenden besonderen Faktoren berücksichtigen:

Verwendung der Datendefinitionssprache (DDL)

Die DDL-Anweisungen sind je nach IBM Datenbankprodukt unterschiedlich, da der Speicher auf verschiedenen Systemen unterschiedlich verwaltet wird. Auf Host- oder AS/400-Server-Systemen können zwischen dem Entwurf einer Datenbank und der Ausgabe der Anweisung CREATE TABLE mehrere Schritte liegen. So wird beispielsweise durch eine Reihe von Anweisungen der Entwurf von logischen Objekten in die physische Darstellung dieser Objekte im Speicher umgesetzt.

Der Precompiler übergibt viele dieser DDL-Anweisungen an den Host- oder AS/400-Server, wenn Sie für eine Host- oder AS/400-Server-Datenbank eine Vorkompilierung durchführen. Dieselben Anweisungen können nicht verwendet werden, um eine Vorkompilierung für eine Datenbank auf dem System auszuführen, auf dem die Anwendung aktiv ist. In einer OS/2-Anwendung beispielsweise führt die Anweisung CREATE STORGROUP eine erfolgreiche Kompilierung für eine DB2 Universal Database für OS/390-Datenbank durch, aber nicht für eine DB2 für OS/2-Datenbank.

Verwendung der Datenbearbeitungssprache (DML)

Im allgemeinen sind DML-Anweisungen in hohem Maße übertragbar. Die Anweisungen SELECT, INSERT, UPDATE und DELETE sind bei den verschiedenen relationalen IBM Datenbanken ähnlich. Bei den meisten Anwendungen werden hauptsächlich DML-SQL-Anweisungen verwendet, die von DB2 Connect unterstützt werden.

Numerische Datentypen

Bei der Übertragung von numerischen Daten auf DB2 Universal Database ändert sich möglicherweise der Datentyp. Numerische und gezont dezimale SQLTYPE-Werte, die von DB2 Universal Database für AS/400 unterstützt werden, werden in fixierte (gepackte) dezimale SQLTYPE-Werte umgesetzt.

Mischbytedaten

Mischbytedaten können in derselben Spalte aus Zeichen des Zeichensatzes eines erweiterten UNIX-Codes (EUC), einem Doppelbytezeichensatz (DBCS) und einem Einzelbytezeichensatz (SBCS) bestehen. Auf Systemen, die Daten im EBCDIC-Format speichern (OS/390, OS/400, VSE und VM), markieren DBCS-Startzeichen und DBCS-Endezeichen den Anfang und das Ende der DBCS-Daten. Auf Systemen, die Daten im ASCII-Format speichern (beispielsweise OS/2 und UNIX), sind DBCS-Startzeichen und DBCS-Endezeichen nicht erforderlich.

Wenn Ihre Anwendung Mischbytedaten von einem ASCII-System auf ein EBCDIC-System überträgt, achten Sie darauf, ausreichend Platz für die Start- und Endezeichen zu lassen. Fügen Sie der Datenlänge für jeden Wechsel von SBCS-Daten zu DBCS-Daten 2 Byte hinzu. Um eine bessere Übertragbarkeit zu erreichen, sollten Sie für Anwendungen, die Mischbytedaten verwenden, Zeichenfolgen mit variabler Länge einsetzen.

Langfelder

Langfelder (Zeichenfolgen mit mehr als 254 Zeichen) werden auf verschiedenen Systemen unterschiedlich verarbeitet. Ein Host- oder AS/400-Server unterstützt möglicherweise nur einen Teilsatz von Skalarfunktionen für Langfelder. DB2 Universal Database für OS/390 beispielsweise läßt für Langfelder nur die Funktionen LENGTH und SUBSTR zu. Auch erfordert ein Host- oder AS/400-Server unter Umständen eine unterschiedliche Verarbeitung bestimmter SQL-Anweisungen. DB2 für VSE & VM beispielsweise verlangt, daß mit der Anweisung INSERT lediglich die Host-Variable SQLDA oder der Wert NULL verwendet wird.

Datentyp LOB (Großes Objekt)

Der Datentyp LOB (Large Objekt; großes Objekt) wird von DB2 Connect unterstützt.

Benutzerdefinierte Datentypen (UDTs)

DB2 Connect unterstützt lediglich benutzerdefinierte einzigartige Datentypen. Abstrakte Datentypen werden nicht unterstützt.

Datentyp ROWID

Der Datentyp ROWID wird von DB2 Connect als Zeichen mit variabler Länge (VARCHAR) für Bitdaten verarbeitet.

Datentyp für ganze 64-Bit-Zahlen (BIGINT)

DB2 Connect unterstützt ganze 8-Byte-Zahlen (64 Bit). Der interne Datentyp BIGINT wird verwendet, um die Kardinalität sehr großer Datenbanken bei gleichzeitiger Gewährleistung der Datengenauigkeit zu unterstützen.

Verwendung der Datensteuerungssprache (DCL)

Alle Verwaltungssysteme für relationale Datenbanken von IBM verfügen über verschiedene Unterteilungsstufen für die SQL-Anweisungen GRANT und REVOKE. Bitte überprüfen Sie anhand der produktspezifischen Veröffentlichungen, welche SQL-Anweisungen für das jeweilige Datenbankverwaltungssystem zu verwenden sind.

Verbindungen herstellen und unterbrechen

DB2 Connect unterstützt sowohl die Versionen CONNECT TO und CONNECT RESET der Anweisung CONNECT als auch CONNECT ohne Parameter. Wenn eine Anwendung eine SQL-Anweisung aufruft, ohne zuvor eine explizite CONNECT TO-Anweisung auszuführen, wird eine implizite Verbindung zum standardmäßigen Anwendungs-Server (sofern definiert) hergestellt.

Wenn Sie eine Verbindung zu einer Datenbank herstellen, werden im Feld SQLERRP des SQL-Kommunikationsbereichs (SQLCA) Informationen zur Identifizierung des Verwaltungssystems für relationale Datenbanken zurückgegeben. Wenn es sich beim Anwendungs-Server um eine relationale IBM Datenbank handelt, enthalten die ersten drei Byte im Feld SQLERRP eine der folgenden Angaben:

DSN
DB2 Universal Database für OS/390

ARI
DB2 für VSE & VM

QSQ
DB2 Universal Database für AS/400

SQL
DB2 Universal Database.

Wenn Sie während der Verwendung von DB2 Connect die Anweisung CONNECT TO oder eine leere CONNECT-Anweisung ausgeben, wird der Landescode oder der Gebiets-Token im Feld SQLERRMC des SQL-Kommunikationsbereichs (SQLCA) als Leerzeichen zurückgegeben. Die ID für den codierten Zeichensatz (CCSID) des Anwendungs-Servers wird im Token der Codepage oder des codierten Zeichensatzes zurückgegeben.

Sie können eine Verbindung mit den folgenden Anweisungen explizit unterbrechen: CONNECT RESET (bei Typ-1-Verbindungen), RELEASE und COMMIT (bei Typ-2-Verbindungen) oder DISCONNECT (beide Verbindungstypen, jedoch nicht in einer TP-Monitor-Umgebung).

Wenn eine Verbindung nicht explizit unterbrochen wird und die Anwendung normal beendet wird, schreibt DB2 Connect die Ergebnisdaten implizit fest (COMMIT).
Anmerkung:Eine Anwendung kann SQLCODE-Werte empfangen, die auf Fehler hinweisen, und dennoch normal beendet werden; in diesem Fall schreibt DB2 Connect die Daten fest. Wenn Sie keine Festschreibung der Daten wünschen, müssen Sie den Befehl ROLLBACK ausgeben.

Mit dem Befehl FORCE können Sie Verbindungen einzelner ausgewählter oder aller Benutzer zur Datenbank unterbrechen. Dieser Befehl wird für Host- oder AS/400-Server-Datenbanken unterstützt. Benutzer können zum Verlassen der DB2 Connect-Workstation gezwungen werden.

Vorkompilierung

Die Precompiler für verschiedene relationale Datenbanken von IBM weisen einige Unterschiede auf. Der Precompiler für DB2 Universal Database unterscheidet sich folgendermaßen von den Precompilern für Host- bzw. AS/400-Server:

Blockung

DB2 Connect unterstützt die folgenden Bindeoptionen für Blockung des DB2-Datenbankmanagers:

UNAMBIG
Nur eindeutige Cursor werden geblockt (Standard).

ALL
Mehrdeutige Cursor werden geblockt.

NO
Cursor werden nicht geblockt.

DB2 Connect verwendet die Blockgröße, die in der Konfigurationsdatei des DB2-Datenbankmanagers für das Feld RQRIOBLK definiert ist. Die aktuellen Versionen von DB2 Connect unterstützen Blockgrößen bis zu 32 767. Wenn in der Konfigurationsdatei des DB2-Datenbankmanagers größere Werte angegeben werden, verwendet DB2 Connect den Wert 32 767, setzt die Konfigurationsdatei des DB2-Datenbankmanagers jedoch nicht zurück. Die Blockung wird auf dieselbe Weise verarbeitet; für dynamisches und statisches SQL wird dieselbe Blockgröße verwendet.
Anmerkung:Die meisten Host- bzw. AS/400-Server-Systeme betrachten dynamische Cursor als mehrdeutig; DB2 Universal Database-Systeme betrachten einige dynamische Cursor jedoch als eindeutig. Um Mißverständnisse zu vermeiden, können Sie bei DB2 Connect BLOCKING ALL angeben.

Geben Sie die Blockgröße in der Konfigurationsdatei des DB2-Datenbankmanagers über den Befehlszeilenprozessor (CLP), die Steuerzentrale oder eine API an (vgl. die Handbücher Administrative API Reference und Command Reference).

Paketattribute

Ein Paket hat die folgenden Attribute:

Objektgruppen-ID
Die ID des Pakets. Sie kann im Befehl PREP angegeben werden.

Eigner
Die Berechtigungs-ID des Paketeigners. Sie kann im Befehl PREP oder BIND angegeben werden.

Ersteller
Der Benutzername, der das Paket bindet.

Qualifikationsmerkmal
Das implizite Qualifikationsmerkmal für Objekte im Paket. Es kann im Befehl PREP oder BIND angegeben werden.

Alle Host- oder AS/400-Server-Systeme weisen Einschränkung hinsichtlich der Verwendung dieser Attribute auf:

DB2 Universal Database für OS/390
Alle vier Attribute können unterschiedlich sein. Die Verwendung eines anderen Qualifikationsmerkmals erfordert besondere Administratorberechtigungen. Das Handbuch Command Reference für DB2 Universal Database für OS/390 enthält weitere Informationen zu den Bedingungen hinsichtlich der Verwendung dieser Attribute.

DB2 für VSE & VM
Alle Attribute müssen identisch sein. Wenn USER1 (mit dem Befehl PREP) eine Bindedatei erstellt, und USER2 die eigentliche Bindung ausführt, benötigt USER2 eine DBA-Berechtigung, um die Bindung für USER1 ausführen zu können. Für die Attribute wird nur der Benutzername von USER1 verwendet.

DB2 Universal Database für AS/400
Das Qualifikationsmerkmal gibt den Namen der Objektgruppe an. Die Beziehung zwischen den Qualifikationsmerkmalen und dem Eigentumsrecht wirkt sich auf das Erteilen und Widerrufen von Berechtigungen für das Objekt aus. Der angemeldete Benutzername ist der Ersteller und Eigner, sofern er nicht durch eine Objektgruppen-ID qualifiziert ist. In diesem Fall ist die Objektgruppen-ID der Eigner. Die Objektgruppen-ID muß bereits existieren, bevor sie als Qualifikationsmerkmal verwendet wird.

DB2 Universal Database
Alle vier Attribute können unterschiedlich sein. Die Verwendung eines anderen Eigners erfordert eine Administratorberechtigung, und der Binder muß für das Schema (falls es bereits existiert) die Berechtigung CREATEIN haben.
Anmerkung:DB2 Connect unterstützt den Befehl SET CURRENT PACKAGESET für DB2 Universal Database für OS/390 und DB2 Universal Database.

Auf Null endende C-Zeichenfolgen

Die Bindeoption CNULREQD setzt die Verarbeitung von auf Null endenden Zeichenfolgen, die mit der Option LANGLEVEL angegeben wurden, außer Kraft.

Das Handbuch Application Development Guide enthält eine Beschreibung dazu, wie auf Null endende Zeichenfolgen verarbeitet werden, wenn sie mit der Option LANGLEVEL mit der Einstellung MIA oder SAA1 vorbereitet wurden.

Der Standardwert für CNULREQD ist YES. Dadurch werden auf Null endende Zeichenfolgen gemäß MIA-Standards interpretiert. Bei der Herstellung einer Verbindung zu einem Server von DB2 Universal Database für OS/390 wird dringend empfohlen, für CNULREQD den Wert YES einzustellen. Anwendungen, die gemäß SAA1-Standards codiert sind (bezüglich auf Null endender Zeichenfolgen), müssen mit einer CNULREQD-Option gebunden werden, die auf den Wert NO eingestellt ist. Andernfalls werden auf Null endende Zeichenfolgen gemäß MIA-Standards interpretiert, selbst wenn sie mit einer auf den Wert SAA1 eingestellten LANGLEVEL-Option vorbereitet wurden.

Eigenständige Variablen SQLCODE und SQLSTATE

Die eigenständigen Variablen SQLCODE und SQLSTATE (gemäß Definition in ISO/ANS SQL92) werden über die LANGLEVEL-Vorkompilieroption SQL92E unterstützt. Beim Vorkompilieren wird die Warnung SQL0020W ausgegeben. Sie gibt an, daß LANGLEVEL nicht unterstützt wird. Diese Warnung gilt lediglich für die im Handbuch Command Reference unter LANGLEVEL MIA aufgelisteten Funktionen, die einen Teilsatz von LANGLEVEL SQL92E darstellen.

Definition einer Sortierreihenfolge

Die Unterschiede zwischen EBCDIC und ASCII führen zu unterschiedlichen Sortierreihenfolgen in den verschiedenen Datenbankprodukten und wirken sich auch auf die Klauseln ORDER BY und GROUP BY aus. Eine Methode zur Minimierung dieser Unterschiede besteht darin, eine benutzerdefinierte Sortierfolge zu erstellen, die die Sortierreihenfolge von EBCDIC nachahmt. Sie können eine Sortierfolge nur beim Erstellen einer neuen Datenbank angeben. Die Handbücher Application Development Guide, Administrative API Reference und Command Reference enthalten weitere Informationen hierzu.
Anmerkung:Datenbanktabellen können unter DB2 Universal Database für OS/390 jetzt im ASCII-Format gespeichert werden. Dies ermöglicht einen schnelleren Austausch von Daten zwischen DB2 Connect und DB2 Universal Database für OS/390. Außerdem sind keine Feldprozeduren mehr erforderlich, die ansonsten verwendet werden müssen, um Daten umzusetzen und umzusortieren.

Verwaltung der referentiellen Integrität

Verschiedene Systeme verarbeiten referentielle Integritätsbedingungen auf unterschiedliche Weise:

DB2 Universal Database für OS/390
Bevor mit dem Primärschlüssel ein Fremdschlüssel erstellt werden kann, muß für den Primärschlüssel ein Index erstellt werden. Tabellen können auf sich selbst verweisen.

DB2 für VSE & VM
Für einen Fremdschlüssel wird automatisch ein Index erstellt. Tabellen können nicht auf sich selbst verweisen.

DB2 Universal Database für AS/400
Für einen Fremdschlüssel wird automatisch ein Index erstellt. Tabellen können auf sich selbst verweisen.

DB2 Universal Database
Bei DB2 Universal Database-Datenbanken wird automatisch ein Index für eindeutige Integritätsbedingungen erstellt, einschließlich eines Primärschlüssels. Tabellen können auf sich selbst verweisen.

Andere Regeln unterscheiden sich hinsichtlich der Stufen der überlappenden Anordnung.

Sperren

Die vom Datenbank-Server verwendete Sperrmethode kann Auswirkungen auf einige Anwendungen haben. Anwendungen beispielsweise, die auf der Grundlage von Sperren auf Zeilenebene und der Isolationsstufe der Cursorstabilität aufgebaut sind, können nicht direkt auf Systeme übertragen werden, die Sperren auf Seitenebene ausführen. Wegen der zugrunde liegenden Unterschiede müssen die Anwendungen unter Umständen angepaßt werden.

DB2 Universal Database für OS/390 und DB2 Universal Database können ein Zeitlimit für Sperren setzen und einen Fehlercode an Anwendungen im Wartestatus senden.

Unterschiede bei SQLCODE- und SQLSTATE-Werten

Verschiedene IBM Produkte für relationale Datenbanken erzeugen nicht immer die gleichen SQLCODE-Werte für ähnliche Fehler. Sie haben zwei Möglichkeiten, um dieses Problem zu lösen:

Verwendung von Systemkatalogen

Verschiedene IBM Datenbanken haben unterschiedliche Systemkataloge. Viele Unterschiede können durch die Verwendung von Sichten maskiert werden. Die Dokumentation des von Ihnen verwendeten Datenbank-Servers enthält entsprechende Informationen.

Die Katalogfunktionen in CLI umgehen dieses Problem durch Unterstützung derselben API und Ergebnismengen für Katalogabfragen in der gesamten DB2-Produktfamilie.

Numerische Umsetzungsüberläufe bei Abfragezuordnungen

Numerische Umsetzungsüberläufe bei Abfragezuordnungen werden von verschiedenen relationalen IBM Datenbanken möglicherweise unterschiedlich verarbeitet. Betrachten Sie beispielsweise den Abruf einer Gleitkommaspalte für eine ganzzahlige Host-Variable von DB2 Universal Database für OS/390 und von DB2 Universal Database. Beim Umsetzen des Gleitkommawertes in einen ganzzahligen Wert kann es zu einem Umsetzungsüberlauf kommen. DB2 Universal Database für OS/390 gibt standardmäßig einen SQLCODE-Wert als Warnung und einen Nullwert an die Anwendung zurück. Im Gegensatz dazu gibt DB2 Universal Database einen Umsetzungsüberlauffehler zurück. Es wird empfohlen, daß in Anwendungen numerische Umsetzungsüberläufe bei Abfragezuordnungen zu vermeiden, indem Werte für Host-Variablen mit angemessener Größe abgerufen werden.

Isolationsstufen

DB2 Connect akzeptiert beim Vorbereiten (PREP) oder Binden (BIND) von Anwendungen die folgenden Isolationsstufen:

RR
Repeatable Read (Wiederholtes Lesen)

RS
Read Stability (Lesestabilität)

CS
Cursor Stability (Cursorstabilität)

UR
Uncommitted Read (Nicht festgeschriebener Lesevorgang)

NC
No Commit (Kein Festschreiben)

Die Reihenfolge der aufgelisteten Isolationsstufen verläuft vom größten Schutz bis hin zum geringsten Schutz. Wenn der Host- oder AS/400-Server die von Ihnen angegebene Isolationsstufe nicht unterstützt, wird die nächst höhere der unterstützten Stufen verwendet.

Tabelle 2 zeigt das Ergebnis der jeweiligen Isolationsstufe auf dem entsprechenden Host- oder AS/400-Anwendungs-Server.

Tabelle 2. Isolationsstufen
DB2 Connect DB2 Universal Database für OS/390 DB2 für VSE & VM DB2 Universal Database für AS/400 DB2 Universal Database
RR RR RR Anmerkung 1 RR
RS Anmerkung 2 RR COMMIT(*ALL) RS
CS CS CS COMMIT(*CS) CS
UR Anmerkung 3 CS COMMIT(*CHG) UR
NC Anmerkung 4 Anmerkung 5 COMMIT(*NONE) UR

Anmerkungen:

  1. Es gibt keine äquivalente COMMIT-Option unter DB2 Universal Database für AS/400, die RR entspricht. DB2 Universal Database für AS/400 unterstützt RR durch Sperren der gesamten Tabelle.

  2. Ergebnisse bei RR für Version 3.1 und Ergebnisse bei RS für Version 4.1 mit APAR PN75407 oder Version 5.1.

  3. Ergebnisse bei CS für Version 3.1 und Ergebnisse bei UR für Version 4.1 oder Version 5.1.

  4. Ergebnisse bei CS für Version 3.1 und Ergebnisse bei UR für Version 4.1 mit APAR PN60988 oder Version 5.1.

  5. Die Isolationsstufe NC wird von DB2 für VSE & VM nicht unterstützt.

Mit DB2 Universal Database für AS/400 können Sie auf eine Tabelle ohne Journal zugreifen, wenn eine Anwendung mit der Isolationsstufe UR gebunden und der Wert für die Blockung auf ALL eingestellt wird oder wenn die Isolationsstufe NC eingestellt wird.

Gespeicherte Prozeduren

Stored Procedure Builder

DB2 Stored Procedure Builder stellt eine benutzerfreundliche Entwicklungsumgebung für das Erstellen, Installieren und Testen von gespeicherten Prozeduren zur Verfügung. So haben Sie die Möglichkeit, sich auf das Erstellen der Logik für gespeicherte Prozeduren zu konzentrieren, anstatt auf die Einzelheiten der Registrierung, Erstellung und Installation dieser Prozeduren auf einem DB2-Server. Mit Stored Procedure Builder können Sie außerdem gespeicherte Prozeduren auf einem Betriebssystem entwickeln und auf anderen Server-Betriebssystemen erstellen.

Stored Procedure Builder ist eine grafische Anwendung, die eine schnelle Entwicklung unterstützt. Mit Stored Procedure Builder können Sie die folgenden Tasks ausführen:

Sie können Stored Procedure Builder als separate Anwendung über die Programmgruppe von DB2 Universal Database starten oder über eine der folgenden Entwicklungsanwendungen:

Sie können Stored Procedure Builder auch über die Steuerzentrale von DB2 für OS/390 starten. Sie können Stored Procedure Builder als separaten Prozeß entweder über das Tools-Menü, die Funktionsleiste oder den Ordner für die gespeicherten Prozeduren in der Steuerzentrale starten. Außerdem können Sie über das Fenster 'Stored Procedure Builder-Projekt' eine oder mehrere ausgewählte gespeicherte SQL-Prozedur(en), die für einen DB2 für OS/390-Server erstellt wurde(n), in eine angegebene Datei exportieren, die innerhalb des Befehlszeilenprozessors (CLP) ausgeführt werden kann.

Stored Procedure Builder verwaltet Ihre Arbeit mit Hilfe von Projekten. Jedes Stored Procedure Builder-Projekt speichert Ihre Verbindungen zu bestimmten Datenbanken wie beispielsweise DB2 für OS/390-Servern. Außerdem können Sie Filter erstellen, um Teilsätze der gespeicherten Prozeduren auf den jeweiligen Datenbanken anzuzeigen. Wenn Sie ein neues oder bestehendes Stored Procedure Builder-Projekt öffnen, können Sie gespeicherte Prozeduren filtern und nach Namen, Schemata, Sprachen oder Objektgruppen-IDs (nur für OS/390) anzeigen lassen.

Verbindungsinformationen werden in Stored Procedure Builder-Projekten gespeichert. Wenn Sie ein bestehendes Projekt öffnen, werden Sie daher automatisch aufgefordert, Ihre Benutzer-ID und Ihr Kennwort für die Datenbank einzugeben. Mit dem Assistenten zum Einfügen von gespeicherten SQL-Prozeduren können Sie gespeicherte SQL-Prozeduren auf einem DB2 für OS/390-Server erstellen. Für alle gespeicherten SQL-Prozeduren, die auf einem DB2 für OS/390-Server erstellt wurden, können Sie spezifische Optionen für das Kompilieren, das Binden sowie für Vorabverbindungen, Verbindungen, die Laufzeit, WLM-Umgebung und externe Sicherheit einstellen.

Außerdem haben Sie die Möglichkeit, Informationen zum Ressourcenverbrauch der SQL-Prozedur abzurufen, einschließlich Informationen über die CPU-Zeit und andere Informationen zum DB2-Ressourcenverbrauch für den Thread, in dem die gespeicherte SQL-Prozedur ausgeführt wird. Insbesondere können Sie Informationen zum Ressourcenverbrauch im Hinblick auf folgendes abrufen: die Wartezeit bei Verriegelungs-/Zugriffskonflikten, die Anzahl der GETPAGE-Operationen, die Anzahl der Ein-/Ausgaben für Lesevorgänge (READ) und die Anzahl der Ein-/Ausgaben für Schreibvorgänge (WRITE).

Zum Abrufen von Informationen zum Ressourcenverbrauch stellt Stored Procedure Builder eine Verbindung zu einem DB2 für OS/390-Server her, führt die SQL-Anweisung aus und ruft eine gespeicherte Prozedur (DSNWSPM) auf, um zu ermitteln, wieviel CPU-Zeit die gespeicherte SQL-Prozedur verwendet hat.

Nicht ganzheitliche Compound-SQL-Anweisung

Mit der Compound-SQL-Anweisung können mehrere SQL-Anweisungen zu einem einzigen ausführbaren Block zusammengefaßt werden. Hierdurch kann der Systemaufwand für das Netzwerk verringert werden, und die Antwortzeiten lassen sich verbessern.

DB2 Connect unterstützt die nicht ganzheitliche Compound-SQL-Anweisung. Dies bedeutet, daß die Verarbeitung der Compound-SQL-Anweisung nach einem Fehler fortgesetzt wird. (Bei der ganzheitlichen Compound-SQL-Anweisung, die von DB2 Connect nicht unterstützt wird, würde nach einem Fehler die gesamte Gruppe der Compound-SQL-Anweisung zurückgesetzt werden.)

Die Anweisungen werden weiterhin ausgeführt, bis sie vom Anwendungs-Server beendet werden. Im allgemeinen wird die Ausführung der Compound-SQL-Anweisung nur im Falle von schwerwiegenden Fehlern gestoppt.

Die nicht ganzheitliche Compound-SQL-Anweisung kann mit allen unterstützten Host- oder AS/400-Anwendungs-Servern verwendet werden.

Wenn mehrere SQL-Fehler auftreten, werden die SQLSTATE-Werte der ersten sieben fehlgeschlagenen Anweisungen im Feld SQLERRMC des SQL-Kommunikationsbereichs (SQLCA) mit der Nachricht zurückgegeben, daß mehrere Fehler aufgetreten sind. Weitere Informationen finden Sie im Handbuch SQL Reference.

Aktualisierung für mehrere Standorte mit DB2 Connect

DB2 Connect ermöglicht eine Aktualisierung für mehrere Standorte, auch zweiphasige Festschreibung genannt. Hierbei handelt es sich um die Aktualisierung mehrerer Datenbanken innerhalb einer einzelnen verteilten Arbeitseinheit (DUOW). Ob Sie diese Funktion verwenden können, hängt von mehreren Faktoren ab:

Host- oder AS/400-Server - Von DB2 Connect unterstützte SQL-Anweisungen

Die folgenden Anweisungen werden erfolgreich für die Verarbeitung mit Host- oder AS/400-Servern kompiliert, nicht jedoch für die Verarbeitung mit DB2 Universal Database-Systemen:

Diese Anweisungen werden auch vom Befehlszeilenprozessor unterstützt.

Die folgenden Anweisungen werden für die Verarbeitung mit Host- oder AS/400-Servern unterstützt, werden jedoch nicht der Bindedatei oder dem Paket hinzugefügt und auch nicht vom Befehlszeilenprozessor unterstützt:

Der Precompiler setzt folgendes voraus:

Host- oder AS/400-Server - Von DB2 Connect zurückgewiesene SQL-Anweisungen

Die folgenden SQL-Anweisungen werden weder von DB2 Connect noch vom Befehlszeilenprozessor unterstützt:

Erweiterte dynamische SQL-Anweisungen von DB2 für VSE & VM werden mit -104 und SQLCODE-Werten für Syntaxfehler zurückgewiesen.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]