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:
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.
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.
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 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 (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.
Der Datentyp LOB (Large Objekt; großes Objekt) wird von DB2 Connect unterstützt.
DB2 Connect unterstützt lediglich benutzerdefinierte einzigartige Datentypen. Abstrakte Datentypen werden nicht unterstützt.
Der Datentyp ROWID wird von DB2 Connect als Zeichen mit variabler Länge (VARCHAR) für Bitdaten verarbeitet.
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.
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.
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:
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.
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:
DB2 Connect unterstützt die folgenden Bindeoptionen für Blockung des DB2-Datenbankmanagers:
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).
Ein Paket hat die folgenden Attribute:
Alle Host- oder AS/400-Server-Systeme weisen Einschränkung hinsichtlich der Verwendung dieser Attribute auf:
Anmerkung: | DB2 Connect unterstützt den Befehl SET CURRENT PACKAGESET für DB2 Universal Database für OS/390 und DB2 Universal Database. |
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.
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.
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. |
Verschiedene Systeme verarbeiten referentielle Integritätsbedingungen auf unterschiedliche Weise:
Andere Regeln unterscheiden sich hinsichtlich der Stufen der überlappenden Anordnung.
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.
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:
SQLSTATE-Werte haben in allen Datenbanken in etwa dieselbe Bedeutung, und die Produkte erstellen SQLSTATE-Werte, die den SQLCODE-Werten entsprechen.
Standardmäßig ordnet DB2 Connect SQLCODE-Werte und Token von jedem IBM Host- oder AS/400-Server-System entsprechenden Werten auf Ihrem DB2 Universal Database-System zu. Sie können eine eigene SQLCODE-Zuordnungsdatei angeben, wenn Sie die Standardzuordnung außer Kraft setzen wollen oder wenn Sie einen Datenbank-Server verwenden, der über keine SQLCODE-Zuordnung verfügt (Datenbank-Server eines anderen Herstellers als IBM). Sie können die SQLCODE-Zuordnung auch ausschalten.
Weitere Informationen finden Sie in Kapitel 11, SQLCODE-Zuordnung.
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 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.
DB2 Connect akzeptiert beim Vorbereiten (PREP) oder Binden (BIND) von Anwendungen die folgenden Isolationsstufen:
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.
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:
|
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.
Ein Client-Programm kann durch Ausgabe der SQL-Anweisung CALL ein Server-Programm aufrufen. In diesem Fall weist die Funktionsweise jedes Servers kleine Unterschiede zu den anderen Servern auf.
Alle CALL-Anweisungen an DB2 für AS/400 von REXX/SQL müssen von der Anwendung dynamisch vorbereitet und ausgeführt werden, da die in REXX/SQL implementierte Anweisung CALL zu CALL USING DESCRIPTOR zugeordnet wird.
Das Handbuch SQL Reference enthält Informationen zur Syntax der SQL-Anweisung CALL. Das Handbuch Application Development Guide enthält Informationen dazu, wie gespeicherte Prozeduren beim Schreiben von Anwendungsprogrammen verwendet werden.
Sie können das Server-Programm für DB2 Universal Database mit denselben Parameterkonventionen aufrufen, die von Server-Programmen für DB2 Universal Database für OS/390, DB2 Universal Database für AS/400 oder DB2 für VSE & VM verwendet werden. Weitere Informationen dazu, wie gespeicherte Prozeduren von DB2 Universal Database aufgerufen werden, und das Handbuch Application Development Guide. Weitere Informationen zu den Parameterkonventionen auf anderen Plattformen enthält die DB2-Produktdokumentation der betreffenden Plattform.
Alle SQL-Anweisungen in einer gespeicherten Prozedur werden als Teil der SQL-Arbeitseinheit ausgeführt, die vom SQL-Client-Programm gestartet wird.
Im Hinblick auf DB2 Universal Database übergeben die Systeme alles, was Sie in die Bezugswertvariablen eingeben. Wenn Sie jedoch DB2 Connect verwenden, können Sie in den Bezugswertvariablen lediglich 0, -1 und -128 übergeben.
Ein Server-Programm unter DB2 Universal Database kann den SQL-Kommunikationsbereich (SQLCA) aktualisieren, so daß alle Fehler oder Warnungen zurückgegeben werden. Gespeicherte Prozeduren unter DB2 Universal Database für OS/390 oder DB2 Universal Database für AS/400 verfügen jedoch über keine solche Unterstützung. Wenn Sie einen Fehlercode von Ihrer gespeicherten Prozedur zurückgeben wollen, müssen Sie ihn als Parameter übergeben. Der SQLCODE- und SQLCA-Wert wird vom Server nur für Fehler gesetzt, die vom System ermittelt werden.
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.
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.
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:
Dies gilt für eigenständige Anwendungen unter DB2 UDB und Anwendungen, die durch einen externen Transaktionsverarbeitungsmonitor (TP-Monitor) wie IBM TXSeries, CICS für Open Systems, BEA Tuxedo, Encina Monitor und Microsoft Transaction Server koordiniert werden.
Anmerkung: | vgl. auch Verwenden von DB2 Connect mit TP-Monitoren.vgl. auch DB2 Connect - Verbindungskonzentrator. |
Wenn der Zugriff auf Host-Daten über TCP/IP-Verbindungen von den DB2-Basisanwendungen und den Basisanwendungen des TP-Monitors mit Hilfe eines gemeinsam benutzten DB2 Connect Enterprise Edition-Servers abgewickelt wird, muß der Synchronisationspunktmanager verwendet werden.
Wenn mit Hilfe eines einzelnen DB2 Connect Enterprise Edition-Servers unter Verwendung von SNA- und TCP/IP-Netzwerkprotokollen auf die Host-Daten zugegriffen wird, und zweiphasige Festschreibung erforderlich ist, muß der Synchronisationspunktmanager verwendet werden. Dies gilt für DB2-Anwendungen und Anwendungen des TP-Monitors.
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:
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.