Dieser Abschnitt beschreibt die Inkompatibilitäten, die mit DB2 Universal Database Version 7 eingeführt werden.
WIN | UNIX | OS/2 |
Diese neue Version des Client Application Enabler (CAE) funktioniert nur mit Query Patroller Server Version 7, weil neue gespeicherte Prozeduren vorhanden sind. CAE ist die Anwendungsschnittstelle für DB2, die letzten Endes alle Anwendungen passieren müssen, um auf die Datenbank zuzugreifen.
Wenn diese CAE-Version mit einem Server einer früheren Version ausgeführt wird, wird SQL29001 zurückgegeben.
WIN | UNIX | OS/2 |
Es gibt eine kleinere und entfernt mögliche Inkompatibilität zwischen einem Client einer Version vor Version 7 und einem Server der Version 7, die im Zusammenhang mit Änderungen am SQL-Deskriptorbereich (SQLDA) stehen. Wie im Handbuch Application Development Guide erläutert, kann Byte 8 des zweiten SQLVAR-Feldes nun den Wert X'12' (neben den Werten X'00' und X'01') annehmen. Anwendungen, die den neuen Wert nicht abfangen, können von dieser Erweiterung beeinträchtigt werden.
Da es in zukünftigen Releases noch weitere Erweiterungen an diesem Feld geben kann, sind Entwickler gut beraten, dieses Feld nur auf explizit definierte Werte zu testen.
WIN | UNIX | OS/2 |
Wenn früher eine gespeicherte Java-Prozedur oder eine benutzerdefinierte Funktion (UDF) gestartet wurde, sperrte Java Virtual Machine (JVM) alle Dateien, die in CLASSPATH angegeben waren (einschließlich der Dateien in sqllib/function). JVM verwendete diese Dateien, bis der Datenbankmanager gestoppt wurde. Abhängig von der Umgebung, in der Sie eine gespeicherte Prozedur oder UDF ausführen (d. h. abhängig vom Wert des Konfigurationsparameters keepdari des Datenbankmanagers und davon, ob die gespeicherte Prozedur abgeschirmt (fenced) wird), ermöglicht Ihnen das Aktualisieren (Refresh) von Klassen ein Ersetzen von CLASS- und JAR-Dateien, ohne den Datenbankmanager zu stoppen. Dies unterscheidet sich von der früheren Funktionsweise.
WIN | UNIX | OS/2 |
In der Vergangenheit bewirkte die Installation eines JAR ein Abbrechen aller DARI-Prozesse (Database Application Remote Interface). Auf diese Weise wurde sichergestellt, daß eine neue gespeicherte Prozedurklasse garantiert mit dem nächsten Aufruf ausgewählt wurde. Zur Zeit brechen keine JAR-Befehle DARI-Prozesse ab. Um sicherzustellen, daß Klassen aus neu installierten oder ersetzten JARs ausgewählt werden, müssen Sie den Befehl SQLEJ.REFRESH_CLASSES explizit absetzen.
Eine weitere Inkompatibilität, die durch das Nichtabrechen von DARI-Prozessen eingeführt wird, ist die Tatsache, daß für abgeschirmte (fenced) gespeicherte Prozeduren, wenn der Wert des Konfigurationsparameters keepdari des Datenbankmanagers auf "YES" gesetzt ist, Clients verschiedene Versionen der JAR-Dateien erhalten können. Betrachten Sie folgendes Szenario:
Mit anderen Worten, wenn Klassen nach JAR-Operationen nicht aktualisiert (Refresh) werden, kann eine gespeicherte Prozedur aus verschiedenen Versionen von JARs aufgerufen werden, je nachdem, welche DARI-Prozesse verwendet werden. Dies unterscheidet sich von der früheren Funktionsweise, bei der (durch Abbrechen (Flush) der DARI-Prozesse) sichergestellt war, daß neue Klassen immer verwendet wurden.
| UNIX |
|
Ausführbare 32-Bit-Codedateien (DB2-Anwendungen) funktionieren mit der neuen 64-Bit-Datenbanksteuerkomponente nicht.
Die Anwendung kann nicht verbunden ("gelinkt") werden. Wenn Sie versuchen, 32-Bit-Objekte mit der 64-Bit-Anwendungsbibliothek von DB2 zu verbinden, wird eine Betriebssystemfehlernachricht des Verbindungseditors (Linker) angezeigt.
Die Anwendung muß als ausführbare 64-Bit-Codedatei neu kompiliert und wieder mit den neuen 64-Bit-Bibliotheken von DB2 verbunden (gelinkt) werden.
WIN | UNIX | OS/2 |
Jede benutzerdefinierte Funktion (UDF), die das Längenfeld des Arbeitspuffers ändert, der an die UDF übergeben wurde, empfängt nun einen SQLCODE-Wert -450.
Eine UDF, die das Längenfeld des Arbeitspuffers ändert, schlägt fehl. Die aufrufende Anweisung empfängt den SQLCODE-Wert -450 mit Angabe des Schemas und des bestimmten Namens der Funktion.
Schreiben Sie den Hauptteil der UDF um, so daß das Längenfeld des Arbeitspuffers nicht geändert wird.
WIN | UNIX | OS/2 |
Das Schema SESSION ist das einzig zulässige Schema für temporäre Tabellen und wird nun von DB2 verwendet, um anzuzeigen, daß ein mit SESSION qualifizierter Tabellenname auf eine temporäre Tabelle verweisen kann. Jedoch ist SESSION kein reserviertes Schlüsselwort für temporäre Tabellen und kann als Schema für reguläre Basistabellen verwendet werden. Aus diesem Grund kann eine Anwendung vielleicht sowohl eine richtige Tabelle SESSION.T1 als auch eine deklarierte temporäre Tabelle SESSION.T1 gleichzeitig vorfinden. Wenn beim Binden eines Pakets eine statische Anweisung angetroffen wird, die einen (explizit oder implizit) durch SESSION qualifizierten Tabellenverweis enthält, wird weder ein Abschnitt (Section) noch eine Abhängigkeit für diese Anweisung in den Katalogen gespeichert. Statt dessen muß dieser Abschnitt zur Laufzeit inkrementell gebunden werden. Dadurch wird eine Kopie des Abschnitts in den Cache für dynamisches SQL gestellt, wo die zwischengespeicherte Kopie nur für das eindeutige Exemplar der Anwendung privat ist. Wenn zur Laufzeit eine deklarierte temporäre Tabelle mit übereinstimmendem Tabellennamen vorhanden ist, wird die deklarierte temporäre Tabelle verwendet, selbst wenn eine permanente Basistabelle desselben Namens existiert.
In Version 6 (und früheren) verweisen alle Paketen mit statischen Anweisungen, die Tabellen mit durch SESSION qualifizierten Namen betreffen, immer auf eine permanente Basistabelle. Beim Binden des Pakets werden ein Abschnitt (Section) sowie relevante Abhängigkeitseinträge für diese Anweisung in den Katalogen gespeichert. In Version 7 werden diese Anweisungen nicht zur Bindezeit gebunden und können zur Laufzeit möglicherweise in eine deklarierte temporäre Tabelle des gleichen Namens aufgelöst werden. Daraus können folgende Situationen entstehen:
Zusammengefaßt läßt sich sagen, daß jedes Paket, daß in Version 7 mit statischen Anweisungen gebunden wird, die auf durch SESSION qualifizierte Tabellen verweisen, sich nicht länger wie statisches SQL verhalten, weil sie ein inkrementelles Binden erfordern. Wenn der Anwendungsprozeß eine Anweisung DECLARE GLOBAL TEMPORARY TABLE für eine Tabelle absetzt, die den gleichen Namen wie eine vorhandene, mit SESSION qualifizierte Tabelle, Sicht bzw. ein solcher Aliasname besitzt, werden Verweise auf diese Objekte immer auf die deklarierte temporäre Tabelle bezogen.
Ändern Sie nach Möglichkeit die Schemennamen permanenter Tabellen, so daß nicht SESSION verwendet wird. Ansonsten gibt es keine Abhilfe, außer sich die Auswirkungen auf die Leistung und den möglichen Konflikt mit deklarierten temporären Tabellen bewußt zu machen.
Die folgende Abfrage kann zur Erkennung von Tabellen, Sichten und Aliasnamen verwendet werden, die betroffen sein könnten, wenn eine Anwendung mit temporären Tabellen arbeitet:
select tabschema, tabname from SYSCAT.TABLES where tabschema = 'SESSION'
Die folgende Abfrage kann zur Ermittlung von gebundenen Paketen der Version 7 dienen, für die statische Abschnitte (Sections) in den Katalogen gespeichert sind und deren Funktionsweise sich ändern könnte, wenn das Paket erneut gebunden wird (nur bei Migration von Version 6 zu Version 7 relevant):
select pkgschema, pkgname, bschema, bname from syscat.packagedep where bschema = 'SESSION' and btype in ('T', 'V', 'I')
| UNIX |
|
Data Links File Manager und File System Filter werden unter Solaris OS 2.5.1 nicht unterstützt.
| UNIX |
|
Der Befehl "db2set -ul (user level)" und die zugehörigen Funktionen wurden nicht auf AIX oder Solaris portiert.
WIN | UNIX | OS/2 |
32-Bit-Clients können keine Verbindung zu Exemplaren (Attach) oder Datenbanken (Connect) auf 64-Bit-Servern herstellen.
Wenn sowohl der Client als auch der Server mit Code der Version 7 arbeiten, wird SQL1434N zurückgegeben. Ansonsten schlägt der Verbindungsversuch (Attach oder Connect) mit SQLCODE-Wert -30081 fehl.
Verwenden Sie 64-Bit-Clients.