Dieser Abschnitt beschreibt die Inkompatibilitäten, die mit DB2 Universal Database Version 6 eingeführt werden.
WIN | UNIX | OS/2 |
In den Systemkatalogsichten wurden neue Codes eingeführt: "U" für typisierte Tabellen und "W" für typisierte Sichten.
Abfragen, die in den Systemkatalogen mit dem Typencode "T" nach Tabellen bzw. "V" nach Sichten suchen, finden keine typisierten Tabellen und Sichten mehr.
Verschiedene Systemkataloge, einschließlich der Systemkatalogsichten TABLES, PACKAGEDEP, TRIGDEP und VIEWDEP, haben eine Spalte namens TYPE oder BTYPE, die einen aus einem Buchstaben bestehenden Typencode enthält. In Version 5.2 wurde der Typencode "T" für alle Tabellen und der Typencode "V" für alle Sichten verwendet. In Version 6 haben nicht typisierte Tabellen weiterhin den Typencode "T". Typisierte Tabelle haben dagegen den neuen Typencode "U". Analog dazu haben nicht typisierte Sichten weiterhin den Typencode "V". Typisierte Sichten haben dagegen den neuen Typencode "W". Darüber hinaus wird eine neue Art von Tabelle, eine sogenannte Hierarchietabelle, die nicht direkt von Benutzern erstellt, sondern vom System zur Implementierung von Tabellenhierarchien verwendet wird, in den Systemkatalogtabellen mit dem Typencode "H" angezeigt.
Ändern Sie das Tool oder die Anwendung so, daß die Codes für typisierte Tabellen und Sichten erkannt werden. Wenn das Tool oder die Anwendung eine logische Sicht von Tabellen benötigt, sollten die Typencodes "T", "U", "V" und "W" verwendet werden. Benötigt das Tool oder die Anwendung eine physische Sicht von Tabellen, einschließlich Hierarchietabellen, sollten die Typencodes "T" und "H" verwendet werden.
WIN | UNIX | OS/2 |
In zwei SYSCAT.REFERENCES-Spalten, PK_COLNAMES und FK_COLNAMES, wird der Datentyp von VARCHAR(320) in VARCHAR(640) geändert.
Primärschlüssel- oder Fremdschlüsselspaltennamen werden abgeschnitten, sind nicht korrekt oder fehlen.
Wenn in einem Primärschlüssel oder Fremdschlüssel Spaltennamen verwendet werden, die länger als 18 Byte sind, kann das Format, mit dem die Liste von Spaltennamen in diesen beiden Spalten gespeichert ist, nicht gleich bleiben. Die mit Leerzeichen begrenzten 20 Byte langen Spaltennamen, die auf die Spalte folgen, deren Länge (n) größer als 18 Byte ist, werden um n-18 Byte nach rechts verschoben. Wenn die Liste von Spaltennamen 640 Byte übersteigt, enthält die Spalte auch die leere Zeichenfolge.
Die Sicht SYSCAT.KEYCOLUSE enthält die Liste der Spalten, aus denen ein Primär-, Fremd- oder eindeutiger Schlüssel besteht, und sollte anstelle der Spalten in SYSCAT.REFERENCES verwendet werden. Alternativ dazu können Benutzer die Länge der Spaltennamen auf 18 Byte oder die Gesamtlänge der Spaltenliste auf 640 Byte begrenzen.
WIN | UNIX | OS/2 |
Sichttext in der SYSCAT.VIEWS-Spalte TEXT wird nicht mehr auf mehrere Zeilen verteilt. Der Datentyp wird von VARCHAR(3600) in CLOB(64K) geändert.
Das Tool oder die Anwendung zeigt nicht den vollständigen Sichttext an.
Tools oder Anwendungen, die so codiert sind, daß sie erwarten, daß höchstens 3600 (oder möglicherweise 3900) Byte auf einmal von der Spalte TEXT zurückgegeben werden, können die erhöhte Größe dieses Felds nicht handhaben. Der Mechanismus zum Abrufen mehrerer Zeilen und zum Wiederherstellen des Sichttexts über das Feld SEQNO ist nicht mehr notwendig. Der Wert für SEQNO ist immer 1.
Ändern Sie das Tool oder die Anwendung so, daß Werte aus der Spalte TEXT gehandhabt werden können, die größer als 3600 Byte sind. Alternativ dazu könnte der Sichttext so umgeschrieben werden, daß er 3600 Byte nicht übersteigt.
WIN | UNIX | OS/2 |
Anweisungstext in der SYSCAT.STATEMENTS-Spalte TEXT wird nicht mehr auf mehrere Zeilen verteilt. Der Datentyp wird von VARCHAR(3600) in CLOB(64K) geändert.
Das Tool oder die Anwendung zeigt nicht den vollständigen Anweisungstext an.
Tools oder Anwendungen, die so codiert sind, daß sie erwarten, daß höchstens 3600 (oder möglicherweise 3900) Byte auf einmal von der Spalte TEXT zurückgegeben werden, können die erhöhte Größe dieses Felds nicht handhaben. Der Mechanismus zum Abrufen mehrerer Zeilen und zum Wiederherstellen des Anweisungstexts über das Feld SEQNO ist nicht mehr notwendig. Der Wert für SEQNO ist immer 1.
Ändern Sie das Tool oder die Anwendung so, daß Werte aus der Spalte TEXT gehandhabt werden können, die größer als 3600 Byte sind. Alternativ dazu könnte der Anweisungstext so umgeschrieben werden, daß er 3600 Byte nicht übersteigt.
WIN | UNIX | OS/2 |
Der Datentyp der SYSCAT.INDEXES-Spalte COLNAMES wird von VARCHAR(320) in VARCHAR(640) geändert.
Es fehlen Spaltennamen aus einem Index.
Tools oder Anwendungen, die so codiert sind, daß sie Daten aus einer Spalte mit dem Datentyp VARCHAR(320) abrufen, können die erhöhte Größe dieses Felds nicht handhaben.
Die Sicht SYSCAT.INDEXCOLUSE enthält die Liste von Spalten, aus denen ein Index besteht. Sie sollte anstelle der Spalte COLNAMES verwendet werden. Alternativ dazu können Sie eine Spalte aus dem Index entfernen oder die Größe des Spaltennamens verringern, so daß die Liste von Spaltennamen (mit führendem + oder -) 320 Byte nicht übersteigt.
WIN | UNIX | OS/2 |
Der Datentyp der SYSCAT.CHECKS-Spalte TEXT wird von CLOB(32K) in CLOB(64K) geändert.
Die Klausel für die Prüfung auf Integritätsbedingung ist unvollständig.
Tools oder Anwendungen, die so codiert sind, daß sie Daten aus einer Spalte mit dem Datentyp CLOB(32K) abrufen, können die erhöhte Größe dieses Felds nicht handhaben.
Ändern Sie das Tool oder die Anwendung so, daß Werte aus der Spalte TEXT gehandhabt werden können, die länger als 32 KB sind. Alternativ dazu können Sie die Klausel für die Prüfung auf Integritätsbedingung so umschreiben, daß sie weniger Zeichen verwendet und so 32 KB nicht übersteigt.
WIN | UNIX | OS/2 |
Bei mehreren Spalten von Systemkatalogsichten wurde der Datentyp von INTEGER in BIGINT geändert.
Werte sind viel kleiner (oder größer) als erwartet, insbesondere bei statistischen Daten.
Tools oder Anwendungen, die so codiert sind, daß sie Daten aus einer Spalte mit dem Datentyp INTEGER abrufen, können die erhöhte Größe dieses Felds nicht handhaben.
Ändern Sie das Tool oder die Anwendung so, daß Werte gehandhabt werden können, die größer als der Höchstwert oder kleiner als Mindestwert sind, der in einem INTEGER-Feld gespeichert werden kann. Alternativ dazu können Sie die zugrundeliegende Struktur oder den zugrundeliegenden SQL-Code ändern, durch die/den der Wert aus dem Bereich herausfällt, der durch ein INTEGER-Feld dargestellt werden kann.
WIN | UNIX | OS/2 |
Neue Spalten werden in der SYSCAT-Sichtdefinition nicht am Ende von Sichten eingefügt.
Die erneute Vorverarbeitung schlägt mit mehreren Abweichungen der Spalte oder des Spaltendatentyps fehl.
Neue Spalten werden in die Systemkatalogsichten eingeführt und für eine Sofortabfrageumgebung sinnvoll angeordnet, d. h. kürzere Spalten werden vor sehr langen Spalten angeordnet, und die Spalte REMARKS ist immer die letzte Spalte.
Nennen Sie die Spalten in der SELECT-Liste explizit, statt "SELECT *" zu verwenden.
WIN | UNIX | OS/2 |
SYSCAT.COLUMNS und SYSCAT.ATTRIBUTES enthalten jetzt Einträge für übernommene Spalten und Attribute.
Abfragen auf SYSCAT.COLUMNS zum Abrufen der Spalten einer typisierten Tabelle oder Sicht sowie Abfragen auf SYSCAT.ATTRIBUTES zum Abrufen der Attribute eines strukturierten Typs können in Version 6 mehr Zeilen zurückgeben als in Version 5.2, wenn das Ziel der Abfrage eine untergeordnete Tabelle, eine untergeordnete Sicht oder ein Subtyp ist.
In Version 5.2 enthielten die Kataloge COLUMNS und ATTRIBUTES für eine bestimmte Tabelle, eine bestimmte Sicht oder einen bestimmten strukturierten Typ nur Einträge für Spalten und Attribute, die von dieser Tabelle, dieser Sicht oder diesem Typ eingeführt wurden. Spalten und Attribute, die von übergeordneten Tabellen oder Typen übernommen wurden, wurden nicht in den Katalogen dargestellt. In Version 6 enthalten jetzt die Kataloge COLUMNS und ATTRIBUTES jedoch Einträge für übernommene Spalten und Attribute.
Ändern Sie das Tool oder die Anwendung so, daß die neuen Einträge in den Katalogen COLUMNS und ATTRIBUTES erkannt werden.
WIN | UNIX | OS/2 |
Die rekursiven Katalogsichten im Schema OBJCAT von Version 5.2 werden nicht mehr mit DB2 Universal Database mitgeliefert.
Abfragen, die für die OBJCAT-Katalogsichten geschrieben sind, werden nicht mehr erfolgreich ausgeführt.
Die meisten der Informationen, die bisher in den OBJCAT-Sichten enthalten waren, sind jetzt in normalen SYSCAT-Katalogsichten enthalten. In den meisten Fällen können Sie die Informationen aus den Systemkatalogsichten abrufen. Wenn Sie von Version 5.2 migrieren und die OBJCAT-Katalogsichten vorhanden sind, sollten diese gelöscht werden. Dies kann mit der Befehlszeilenprozessorprozedur objcatdp.db2 im Unterverzeichnis misc des Verzeichnisses sqllib erfolgen.
Sie können auch Ihre eigenen OBJCAT-Sichten erstellen, die zu den in Version 5.2 unterstützten Katalogsichten äquivalent sind.
In Version 5.2 wurden die Benutzer in Anhang E des Handbuchs SQL Reference darauf hingewiesen, daß die OBJCAT-Katalogsichten temporär sind und in zukünftigen Versionen nicht mehr unterstützt werden.
WIN | UNIX | OS/2 |
In den Systemkatalogsichten werden die hierarchischen Abhängigkeiten, die bisher mit dem Code "H" bezeichnet wurden, jetzt mit dem Code "O" bezeichnet.
Abfragen, die in den Katalogsichten mit dem Code "H" nach hierarchischen Abhängigkeiten suchen, funktionieren nicht mehr korrekt.
Verschiedene Systemkataloge, einschließlich der Systemkatalogsichten PACKAGEDEP, TRIGDEP und VIEWDEP, haben eine Spalte namens BTYPE. In Version 5.2 bezeichneten die OBJCAT-Sichten hierarchische Abhängigkeiten mit dem Code "H". In Version 6 werden diese Abhängigkeiten mit dem Code "O" bezeichnet.
Überarbeiten Sie diese Abfragen, so daß sie nach Code "O" suchen.
WIN | UNIX | OS/2 |
Die folgenden Änderungen wurden an den SYSIBM-Basiskatalogtabellen vorgenommen, die Sie vielleicht immer noch statt der SYSCAT-Sichten verwenden:
(War in der Sicht enthalten, aber nur zur künftigen Nutzung reserviert.)
WIN | UNIX | OS/2 |
Die mögliche Maximalgröße des Datentyps VARCHAR (VARGRAPHIC) wurde in Version 6 von 4000 Zeichen (2000 Doppelbytezeichen) auf 32672 Zeichen (16336 Doppelbytezeichen) erhöht.
Eine Anwendung, die Puffer mit einer festen Länge von 4000 Byte für den Datentyp VARCHAR (VARGRAPHIC) verwendet, überschreibt möglicherweise Puffer oder schneidet Daten ab, wenn sie ein VARCHAR-Feld mit mehr als 4000 Byte in einen zu kleinen Puffer abruft. Die CLI-Funktion SQLGetTypeInfo() gibt jetzt die Größe von VARCHAR als 32672 zurück. CLI-Anwendungen, die diesen Wert in Tabellen-DDLs verwenden, erhalten möglicherweise Fehler, weil keine Tabellenbereiche mit ausreichender Seitengröße verfügbar sind. Weitere Informationen zur Größe von Tabellenbereichen finden Sie in Benutzertabellendaten.
Bei der Codierung der Anwendung ist zu empfehlen, zuerst die Spalten der Ergebnismenge (mit der Anweisung DESCRIBE) zu beschreiben und dann Puffer zu verwenden, deren Größe sich nach der von der Anweisung DESCRIBE zurückgelieferten Länge richtet.
WIN | UNIX | OS/2 |
Beim Programmieren von Java in Version 6 verwenden positionierte UPDATE- und DELETE-Anweisungen die Standardberechtigungskennung der Person, die das Cursorpaket gebunden hat. Dies unterscheidet sich von Version 5.2, bei der die Berechtigungskennung der Person verwendet wird, die das Paket ausführt.
Das Paket mit den positionierten UPDATE- und DELETE-Anweisungen wird möglicherweise nicht ausgeführt, da die Berechtigungskennung der Person, die das Paket gebunden hat, keine ausreichende Berechtigung hat.
Der Berechtigungskennung der Person, die das Paket bindet, muß eine ausreichende Berechtigung zum Ausführen der positionierten UPDATE- und DELETE-Anweisungen im Paket erteilt werden. Erteilen Sie die korrekten Zugriffsrechte, und binden Sie das Paket dann erneut.
WIN | UNIX | OS/2 |
In Version 5.2 kann in einem SQLJ-Programm die Klausel FOR UPDATE in einer SELECT-Anweisungen verwendet werden, um die Spalten anzugeben, die in nachfolgenden positionierten UPDATE-Anweisungen aktualisiert werden können. Die Syntax wurde für Version 6 geändert.
Sie erhalten die Fehlernachricht SQJ0204E, wenn eine SELECT-Anweisung eine Klausel FOR UPDATE enthält.
Entfernen Sie die Klausel FOR UPDATE aus der SELECT-Anweisung. Geben Sie einen aktualisierbaren Iterator über die Iteratordeklarationsklausel an. Beispiel:
#sql public iterator DelByName implements sqlj.runtime.ForUpdate(String EmpNo) with updateColumns = (salary);
Wenn Sie explizit angeben wollen, welche Spalten aktualisierbar sind, geben Sie diese über das Schlüsselwort updateColumns in Verbindung mit der Klausel WITH an.
Weitere Informationen zur Deklaration positionierter Iteratoren finden Sie im Handbuch Application Development Guide.
WIN | UNIX | OS/2 |
DB2 Universal Database Version 6 unterstützt 128 Byte lange Tabellen-, Sichten- und Aliasnamen sowie 30 Byte lange Spaltennamen. Bisher wurden 18 Byte lange Namen für alle diese Kategorien unterstützt.
Die Sonderregister USER und CURRENT SCHEMA wurden von CHAR(8) in VARCHAR(128) geändert. Das Sonderregister CURRENT EXPLAIN MODE wurde von CHAR(8) in VARCHAR(254) geändert. Die Ausgabe für die integrierten Funktionen TYPE_SCHEMA und TABLE_SCHEMA wurde von CHAR(8) in VARCHAR(128) geändert.
Wenn Anwendungen, die vor Version 6 entwickelt wurden, für eine Datenbank der Version 6 ausgeführt werden, die die längeren Begrenzungen nicht verwendet, sollte sich das Anwendungsverhalten nicht ändern. Wenn Sie jedoch diese Anwendungen für eine Datenbank der Version 6 ausführen, die längere Namen verwendet, könnte es je nach Codierung dieser Anwendungen zu gewissen Nebeneffekten können.
Es folgen einige Beispiele:
Die beste Möglichkeit, Probleme dieser Art zu beheben, besteht darin, die Anwendung so neu zu codieren, daß sie längere Tabellen- und Spaltenname handhaben kann. Stellen Sie andernfalls sicher, daß diese Anwendungen nicht für Datenbanken der Version 6 ausgeführt werden, die Namen mit mehr als 18 Byte verwenden.
WIN | UNIX | OS/2 |
DB2 Universal Database Version 6 unterstützt 128 Byte lange Tabellen-, Sichten- und Aliasnamen sowie 30 Byte lange Spaltennamen. Bisher wurden 18 Byte lange Namen für alle diese Kategorien unterstützt.
Ein Client unter DB2 Universal Database Version 5 kann keine PC/IXF-Datei importieren, die von einem Client unter DB2 Universal Database Version 6 exportiert wurde (Fehlernachricht SQL3059N). Eine PC/IXF-Datei (exportiert aus einem Client unter DB2 Universal Database Version 6) kann nicht in eine Datenbank von DB2 Universal Database Version 5 geladen werden (Fehlernachricht SQL3059N).
Verwenden Sie beim Importieren oder Laden von PC/IXF-Daten kompatible Versionen von DB2 Universal Database.
WIN | UNIX | OS/2 |
DB2 Universal Database Version 6 unterstützt 30 Byte lange Spaltennamen. Bisher wurden 18 Byte lange Namen unterstützt. In Version 5 war die dokumentierte Funktionsweise, daß "0xFF" in das 30. Byte eines Felds SQLNAME für nicht verdoppelte SQLVAR-Einträge plaziert wurde. Für systemgenerierte Namen und benutzerdefinierte Spaltennamen, die in einer Klausel AS angegeben wurden, wurde auch "0x00" in das 30. Byte eingefügt.
In Version 6 wird "0xFF" nur dann im 30. Byte zurückgegeben, wenn der Name systemgeneriert ist.
Alle Anwendungen, die mit Hilfe des 30. Byte des Felds SQLNAME festzustellen, ob es sich um einen benutzerdefinierten Spaltennamen oder um einen vom System generierten Namen handelt, erhalten unerwartete Ergebnisse bei Logikprüfungen, wenn der benutzerdefinierte Spaltenname 30 Zeichen lang ist. Dies sollte selten vorkommen.
Diese Anwendungen sollten so geändert werden, daß sie nur auf "0xFF" im 30. Byte des Felds SQLNAME prüfen, wenn die Länge dieses Feldes kleiner als 30 ist. In diesem Fall ist der Name benutzerdefiniert.
WIN |
|
|
Bei der Migration zu einer neuen Version von DB2 UDB können Sie die Funktionsweise des DB2-CLI-/ODBC-Treibers durch Angeben einer Gruppe wahlfreier Schlüsselwörter in der Datei db2cli.ini ändern.
In Version 6 sind die Schlüsselwörter TRANSLATEDLL und TRANSLATEOPTION veraltet.
Diese Schlüsselwörter werden ignoriert, wenn sie noch angegeben sind. Das Wegfallen dieser Einstellungen kann zu erkennbaren Veränderungen in der Funktionsweise führen.
Entscheiden Sie anhand der neuen Liste der gültigen Parameter, welche Schlüsselwörter und Einstellungen Ihrer Umgebung entsprechen. Informationen zu diesen Schlüsselwörtern finden Sie im Handbuch CLI Guide and Reference.
WIN | UNIX | OS/2 |
Ausgabedatenströme des Ereignismonitors haben keine Versionssteuerung. Wenn daher Unterstützung für Tabellennamen hinzugefügt wird, die länger als 18-byte Byte sind, muß zu einem Ausgabedatenstromformat gewechselt werden.
Anwendungen, die die Ausgabedatenströme des Ereignismonitors syntaktisch analysieren, funktionieren nicht mehr ordnungsgemäß.
Es gibt zwei Möglichkeiten:
DB2OLDEVMON=evmonname1,evmonname2,...Dabei ist evmonname der Name des Ereignismonitors (Event Monitor), der im alten Datenformat geschrieben werden soll. Beachten Sie, daß auf neue Felder im Ereignismonitor unter dem alten Datenformat nicht zugegriffen werden kann.
| UNIX |
|
Datenübertragungsverbindungswerte (DATALINK-Werte), die under DB2 Universal Database Version 6 eingefügt werden, benötigen 4 Byte mehr Platz im Spaltenwertdeskriptor.
Wenn in Version 5.2 erstellte DATALINK-Spalten aktualisiert werden, sind auf der Datenseite weitere 4 Byte erforderlich, um den neuen Spaltenwert zu speichern. Es ist daher möglicherweise nicht genügend Platz in der Datenseite vorhanden, um die Aktualisierung durchzuführen, und sie muß vielleicht auf eine neue Seite versetzt werden. Dadurch könnte der Aktualisierung der Platz ausgehen.
Sie müssen auf Ihrem System mehr Platz für Aktualisierungen hinzufügen.
WIN | UNIX | OS/2 |
Eine Reihe von Zeichenfolgefunktionen im Schema SYSFUN haben jetzt verbesserte Versionen, die im Schema SYSIBM definiert sind (integrierte Funktionen). Die Funktionsnamen sind LCASE, LTRIM, RTRIM und UCASE.
Beim Vorbereiten von Anweisungen oder beim Erstellen von Sichten können sich die von diesen Funktionen zurückgegebenen Datentypen in Version 6 unterscheiden. Dies kommt daher, daß die integrierten Funktionen (unter dem Schema SYSIBM) normalerweise vor Funktionen im Schema SYSFUN aufgelöst werden.
Es ist keine Maßnahme erforderlich. Normalerweise wird die integrierte Funktion vor der Funktion im Schema SYSFUN ausgewählt. Die frühere Funktionsweise kann durch Tauschen des SQL-Pfads (so daß SYSFUN vor SYSIBM steht) wiederhergestellt werden, jedoch wird die Leistung dadurch beeinträchtigt. Die Funktion der früheren Version kann auch dadurch aufgerufen werden, daß der Funktionsname mit dem Schemenname SYSFUN qualifiziert wird.
Migrierte Pakete, Sichten, Übersichtstabellen, Auslöser und Integritätsbedingungen verwenden weiter die Version aus dem Schema SYSFUN, sofern keine explizite Aktion wie das Binden des Pakets oder das Neuerstellen der Sicht, der Übersichtstabelle, des Auslösers oder der Integritätsbedingung vorgenommen wird.
WIN | UNIX | OS/2 |
Der Status "U" in der Spalte CONST_CHECKED von SYSCAT.TABLES ändert sich anders, wenn eine Anweisung SET INTEGRITY ... OFF ausgeführt wird.
Vor Version 6 änderte sich der Status "U" in CONST_CHECKED in "N", wenn eine Anweisung SET INTEGRITY ... OFF ausgeführt wurde. Jetzt ändert sich der Status "U" in den Status "W".
Es ist keine Maßnahme erforderlich. Der neue Status "W" in der Spalte CONST_CHECKED wird verwendet, um anzugeben, daß der Typ der Integritätsbedingung bisher durch den Benutzer geprüft wurde und daß einige Daten in der Tabelle eventuell auf Integrität geprüft werden müssen.
Der Status "N" klärt nicht darüber auf, ob es alte Daten gibt, die noch nicht durch den Datenbankmanager überprüft wurden. In einer nachfolgenden Anweisung SET INTEGRITY ... IMMEDIATE CHECKED INCREMENTAL muß der Datenbankmanager einen Fehler zurückgeben, weil die Datenintegrität nicht gewährleistet werden kann, wenn nur neue Änderungen geprüft wurden. Andererseits kann der Status "W" zurück in den Status "U" geändert werden (wenn die Option INCREMENTAL angegeben ist), um anzugeben, daß der Benutzer weiterhin für die Integrität der Daten in der Tabelle verantwortlich ist. Wenn die Option INCREMENTAL nicht angegeben wird, wählt der Datenbankmanager die vollständige Verarbeitung, ändert den Status "W" in den Status "Y" und übernimmt die Verantwortung für die Aufrechterhaltung der Datenintegrität.
WIN | UNIX | OS/2 |
Die von den Clients verwendete Methode zum Erstellen einer Datenbank hat sich geändert.
Die Verwendung eines Clients einer früheren Version zur Erstellung einer Datenbank führt zu Fehlern.
Stellen Sie bei der Verwendung eines Clients zur Erstellung einer Datenbank sicher, daß der Client und der Server mit der gleichen Stufe des DB2-Codes arbeiten.
WIN 32-Bit | UNIX | OS/2 |
Die Angabe des Schlüsselworts ONLY (für eine Tabelle) setzt jetzt voraus, daß der Benutzer das SELECT-Zugriffsrecht für alle untergeordneten Tabellen der angegebenen typisierten Tabelle hat. Analog dazu setzt die Angabe des Schlüsselworts ONLY (für eine Sicht) jetzt voraus, daß der Benutzer das SELECT-Zugriffsrecht für alle untergeordneten Sichten der angegebenen typisierten Tabelle hat. In früheren Versionen von DB2 war das SELECT-Zugriffsrecht nur für die angegebene Tabelle oder Sicht erforderlich.
Es gibt zwei mögliche Symptome:
Der Berechtigungs-ID, die ein Paket erneut binden oder eine neue Sicht oder einen neuen Auslöser erstellen soll, sollte das SELECT-Zugriffsrecht für alle untergeordneten Tabellen (und untergeordnete Sichten) der Tabelle (oder Sicht) erteilt werden, die nach dem Schlüsselwort ONLY angegeben ist.
WIN | UNIX | OS/2 |
Die folgenden Profilregistrierdatenbank- oder Umgebungsvariablen sind veraltet:
Diese Variablen werden nicht mehr benötigt.
WIN | UNIX | OS/2 |
Der Typ des Sonderregisters CURRENT EXPLAIN MODE wurde von CHAR(8) in VARCHAR(254) geändert.
Wenn die Anwendung davon ausgeht, daß der Typ immer noch CHAR(8) ist, kann der Wert von 254 auf 8 Byte abgeschnitten werden.
Ändern Sie den Typ aller Host-Variablen, die das Sonderregister lesen, von CHAR(8) in VARCHAR(254).
Diese Änderung ist erforderlich, um zwei neue Werte im Sonderregister CURRENT EXPLAIN MODE unterzubringen. Diese neuen Werte sind EVALUATE INDEXES und RECOMMEND INDEXES.
WIN | UNIX | OS/2 |
Ab Version 6 werden die Parameter USING und SORT BUFFER des Befehls LOAD nicht mehr unterstützt. Diese Parameter werden ignoriert.
Es wird eine Warnung zurückgegeben, die besagt, daß die Parameter USING und SORT BUFFER nicht länger unterstützt und vom Dienstprogramm LOAD ignoriert werden.
Ignorieren Sie die Warnung. Weitere Informationen finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.
WIN |
|
|
In Version 6 wird RUMBA durch PCOMM unter Windows NT, Windows 98 und Windows 95 (jedoch nicht unter Windows 3.1) ersetzt.
Keine
Keine
WIN | UNIX | OS/2 |
Die folgenden Datenbankkonfigurationsparameter sind veraltet:
Entfernen Sie alle Verweise auf diese Parameter aus Ihren Anwendungen.