管理の手引き


DB2 ユニバーサル・データベース バージョン 6 の非互換性

このセクションでは、 DB2 ユニバーサル・データベース バージョン 6 の非互換性について説明します。

システム・カタログの視点

DB2 ユニバーサル・データベース バージョン 6 でのシステム・カタログ視点


WIN UNIX OS/2

変更点

システム・カタログ視点では、新しいコードが導入されています。 タイプ付き表を表す "U" と、タイプ付き視点を表す "W" です。

症状

システム・カタログで表および視点を検索する照会で、 表にタイプ・コード "T" を、視点に "V" をそれぞれ使用する場合、 タイプ付き表および視点が見つかりません。

説明

システム・カタログ視点 TABLES、PACKAGEDEP、TRIGDEP、 および VIEWDEP を含む一部のシステム・カタログには、 1 文字タイプ・コードを含む列 TYPE または BTYPE があります。 バージョン 5.2 では、すべての表にタイプ・コード "T" が、 そしてすべての視点に "V" が使用されていました。 バージョン 6 では、非タイプ付き表のタイプ・コードは "T" のままで、 タイプ付き表には新しいタイプ・コード "U" が割り当てられます。 同様に、非タイプ付き視点のタイプ・コードは "V" のままで、 タイプ付き視点には新しいタイプ・コード "W" が割り当てられます。 また、階層表と呼ばれる新しい種類の表は、 ユーザーが直接作成するものではなく、 システムが表階層を実装するために使用するものですが、 システム・カタログ表にタイプ・コード "H" で表示されます。

解決方法

タイプ付き表または視点のコードを認識できるように、 ツールまたはアプリケーションを変更します。 ツールまたはアプリケーションに表の論理ビューが必要な場合には、 タイプ・コード "T"、"U" 、"V" 、および "W" が使用されます。 ツールまたはアプリケーションに階層表を含む表の物理ビューが必要な場合には、 タイプ・コード "T" および "H" が使用されます。

DB2 ユニバーサル・データベース バージョン 6 での基本および外部キー列名


WIN UNIX OS/2

変更点

2 つの SYSCAT.REFERENCES 列、PK_COLNAMES と FK_COLNAMES のデータ・タイプは、 VARCHAR(320) から VARCHAR(640) に変更されています。

症状

基本キーまたは外部キーの列名が、切り捨てられたか、正しくないか、 または欠落しています。

説明

基本キーまたは外部キーで 18 バイトより長い列名が使用される場合、 これら 2 つの列に列名のリストが保管される形式はもはや同じではありません。 長さ (n) が 18 を超える列に続く、 ブランクで区切られた 20 バイトの列名は、 n-18 バイトだけ右にシフトされます。 同様に、列名のリストが 640 バイトを超える場合には、列には空ストリングが含まれます。

解決方法

SYSCAT.KEYCOLUSE 視点には、 基本、外部、および固有キーを構成する列のリストが含まれており、 SYSCAT.REFERENCES にある列の代わりにこれを使用しなければなりません。 代わりに、ユーザーは列名の名前を 18 バイトに制限するか、 または列のリストの合計の長さを 640 バイトに制限できます。

DB2 ユニバーサル・データベース バージョン 6 での SYSCAT.VIEWS の列 TEXT


WIN UNIX OS/2

変更点

SYSCAT.VIEWS の列 TEXT にある視点テキストは、 複数の行に分割されなくなりました。 データ・タイプは、VARCHAR(3600) から CLOB(64K) に変更されています。

症状

ツールまたはアプリケーションは、完全な視点テキストを提供しません。

説明

一度に TEXT 列から戻される長さが 3600 (または 3900) を超えないことを 想定して作成されたツールまたはアプリケーションは、 このフィールドのサイズの増加に対応できません。 複数の行を検索し、SEQNO フィールドを使用して視点テキストを再構築するメカニズムは、 必要ではなくなりました。 SEQNO 値は常に 1 になります。

解決方法

3600 バイトより大きい TEXT 列からの値を処理できるように、ツールまたはアプリケーションを変更します。 または、視点 TEXT を 3600 バイト以内に収めるように書き直すこともできます。

DB2 ユニバーサル・データベース バージョン 6 での SYSCAT.STATEMENTS の列 TEXT


WIN UNIX OS/2

変更点

SYSCAT.STATEMENTS の列 TEXT にあるステートメント・テキストは、 複数の行に分割されなくなりました。 データ・タイプは、VARCHAR(3600) から CLOB(64K) に変更されています。

症状

ツールまたはアプリケーションは、 完全なステートメント・テキストを提供しません。

説明

一度に TEXT 列から戻される長さが 3600 (または 3900) を超えないことを 想定して作成されたツールまたはアプリケーションは、 このフィールドのサイズの増加に対応できません。 複数の行を検索し、 SEQNO フィールドを使用してステートメント・テキストを再構築するメカニズムは、 必要ではなくなりました。 SEQNO 値は常に 1 になります。

解決方法

3600 バイトより大きい TEXT 列からの値を処理できるように、 ツールまたはアプリケーションを変更します。 または、ステートメント TEXT を 3600 バイト以内に収めるように書き直すこともできます。

DB2 ユニバーサル・データベース バージョン 6 での SYSCAT.INDEXES の列 COLNAMES


WIN UNIX OS/2

変更点

SYSCAT.INDEXES の列 COLNAMES データ・タイプは、 VARCHAR(320) から VARCHAR(640) に変更されています。

症状

列名が索引から欠落しています。

説明

データ・タイプ VARCHAR(320) の列からデータを検索するように作成されたツール またはアプリケーションは、このフィールドのサイズの増加には対応できません。

解決方法

SYSCAT.INDEXCOLUSE 視点には、索引を構成する列のリストが含まれており、 COLNAMES 列の代わりにこれを使用しなければなりません。 あるいは、索引から列を除去するか、列名のサイズを小さくして、 列名のリストが (先頭の + または - も含めて) 320 バイト以内に収まるようにすることもできます。

DB2 ユニバーサル・データベース バージョン 6 での SYSCAT.CHECKS の列 TEXT


WIN UNIX OS/2

変更点

CHECKS 列 TEXT データ・タイプは、CLOB(32K) から CLOB(64K) に変更されています。

症状

検査制約文節が不完全です。

説明

データ・タイプ CLOB(32K) の列からデータを検索するように作成されたツール またはアプリケーションは、このフィールドのサイズの増加には対応できません。

解決方法

32 KB より長い TEXT 列からの値を処理できるように、 ツールまたはアプリケーションを変更します。 あるいは、検査制約文節を書き直して、 32 KB に収まるように文字数を少なくすることもできます。

DB2 ユニバーサル・データベース バージョン 6 での BIGINT の列データ・タイプ


WIN UNIX OS/2

変更点

システム・カタログ視点列の中には、 データ・タイプが INTEGER から BIGINT に変えられているものがあります。

症状

値、特に統計情報の値が、予想より小さすぎ (または大きすぎ) ます。

説明

データ・タイプ INTEGER の列からデータを検索するように作成されたツール またはアプリケーションは、このフィールドのサイズの増加には対応できません。

解決方法

INTEGER フィールドで保管できる最大値または最小値を超える値を処理できるように、 ツールまたはアプリケーションを変更します。 あるいは、INTEGER フィールドで表示できる値を超える原因となっている、 基礎となる構造または SQL コードを変更することもできます。

DB2 ユニバーサル・データベース バージョン 6 での列のミスマッチ


WIN UNIX OS/2

変更点

SYSCAT 視点定義で視点の終わりに新しい列が挿入されません。

症状

複数の列の不一致または列のデータ・タイプの不一致で再プリプロセスに失敗します。

説明

システム・カタログ視点に新しい列が導入されており、随時照会環境で便利な位置にあります。 特に、短い列は非常に長い列の前にあり、REMARKS 列は常に最後にあります。

解決方法

"SELECT *" とコーディングする代わりに、選択リストで列を明示的に指定します。

DB2 ユニバーサル・データベース バージョン 6 での SYSCAT.COLUMNS および SYSCAT.ATTRIBUTES


WIN UNIX OS/2

変更点

SYSCAT.COLUMNS および SYSCAT.ATTRIBUTES には現在、 継承された列および属性のエントリーが入っています。

症状

タイプ付き表または視点の列を検索する SYSCAT.COLUMNS の照会、 および構造型の属性を検索する SYSCAT.ATTRIBUTES の照会は、 照会の対象が副表、副視点、またはサブタイプの場合には、 バージョン 5.2 よりバージョン 6 の方が多くの行を戻す可能性があります。

説明

バージョン 5.2 では、指定された表、視点、または構造タイプについて、 COLUMNS および ATTRIBUTES カタログには、その表、視点、またはタイプにより導入された、 列および属性のエントリーしか含まれていませんでした。 スーパー表またはスーパータイプから継承した列および属性は、 カタログに表示されませんでした。 しかし、バージョン 6 では、COLUMNS および ATTRIBUTES カタログには、 継承された列および属性のエントリーが入ります。

解決方法

COLUMNS および ATTRIBUTES カタログで新しいエントリーを認識するように、 ツールまたはアプリケーションを変更します。

DB2 ユニバーサル・データベース バージョン 6 で OBJCAT 視点がサポートされなくなった


WIN UNIX OS/2

変更点

バージョン 5.2 の OBJCAT スキーマにある再帰的カタログ視点は、 DB2 ユニバーサル・データベース製品の一部として提供されなくなりました。

症状

OBJCAT カタログ視点に対して作成された照会が、正しく実行しません。

解決方法

以前 OBJCAT 視点にあった情報の大半は、正規の SYSCAT カタログ視点に組み込まれています。 たいていの場合、システム・カタログ視点から情報が得られます。 バージョン 5.2 から移行する場合で、OBJCAT カタログ視点が存在する場合には、 これらを除去しなければなりません。 これを実行するには、 ディレクトリー sqllibmisc サブディレクトリーの 下の objcatdp.db2 という CLP スクリプトを実行します。

バージョン 5.2 でサポートされているカタログと同等の、 独自の OBJCAT 視点のセットを作成することもできます。

バージョン 5.2 では、SQL 解説書 の『付録 E』で、 OBJCAT カタログ視点は一時的なものであり、 将来のリリースではサポートされなくなることが警告されていました。

DB2 ユニバーサル・データベース バージョン 6 で従属関係が変更された


WIN UNIX OS/2

変更点

システム・カタログ視点では、 階層従属関係は以前はコード "H" で表示されていましたが、 現在はコード "O" で表示されています。

症状

カタログ視点で、コード "H" によって階層従属性を検索する照会が、 正しく動作しなくなりました。

説明

システム・カタログ視点 PACKAGEDEP、TRIGDEP、 および VIEWDEP を含むいくつかのシステム・カタログには、BTYPE という列があります。 バージョン 5.2 では、OBJCAT 視点は階層従属関係をコード "H" で表示していました。 バージョン 6 では、これらの従属関係はコード "O" で表示されています。

解決方法

コード "O" を検索するように、これらの照会を変更します。

DB2 ユニバーサル・データベース バージョン 6 での SYSIBM 基本カタログ表


WIN UNIX OS/2

変更点

以下に示すのは、現在でも SYSCAT 視点の代わりに使用できる SYSIBM 基本カタログ表の変更点です。

アプリケーション・プログラミング

DB2 ユニバーサル・データベース バージョン 6 での VARCHAR データ・タイプ


WIN UNIX OS/2

変更点

VARCHAR (VARGRAPHIC) データ・タイプの最大許容サイズは、バージョン 6 では、 4000 文字 (2 バイト文字では 2000) から、 32672 文字 (2 バイト文字では 16336) になりました。

症状

VARCHAR (VARGRAPHIC) データ・タイプに 4000 バイトの固定長バッファーを使用するアプリケーションでは、 4000 バイトより大きい VARCHAR フィールドを小さいバッファーに取り出す場合に、 このバッファーを上書きしたり切り捨てたりする可能性があります。 CLI 関数 SQLGetTypeInfo() は、 VARCHAR のサイズとして 32672 を戻すようになりました。 表 DDL 内のこの値を使用する CLI アプリケーションは、 十分なページ・サイズの表スペースを使用できないことが原因でエラーを受け取る可能性があります。 表スペースのページ・サイズについて 詳しくは、ユーザー表データを参照してください。

解決方法

アプリケーションを作成する際には、 先に (DESCRIBE ステートメントを使用して) 結果セットの列を記述して、 次に DESCRIBE ステートメントから戻される長さに基づくバッファーのサイズを 使用することをお勧めします。

DB2 ユニバーサル・データベース バージョン 6 での Java プログラミングの位置指定 UPDATE および DELETE


WIN UNIX OS/2

変更点

バージョン 6 で Java をプログラミングする場合、 位置指定されている UPDATE および DELETE ステートメントは、 カーソル・パッケージをバインドした担当者の許可識別子をデフォルトとして使用します。 これは、パッケージを実行する人の許可識別子が使用されたバージョン 5.2 とは異なります。

症状

位置指定された UPDATE および DELETE ステートメントを含むパッケージが実行しません。 パッケージを結合した人の許可識別子に十分な許可がないことが原因です。

解決方法

パッケージを結合する人の許可識別子には、 このパッケージ内の位置指定された UPDATE ステートメント および DELETE ステートメントを実行するのに十分な許可が授与されなければなりません。 正しい特権を授与し、それからパッケージを再バインドしてください。

DB2 ユニバーサル・データベース バージョン 6 の FOR UPDATE 文節での構文変更


WIN UNIX OS/2

変更点

バージョン 5.2 では、SQLJ プログラムで、 SELECT ステートメントに FOR UPDATE 文節を使用して、 後続の位置指定 UPDATE ステートメントで更新できる列を識別できるようになっていました。 バージョン 6 では構文が変更されています。

症状

SELECT ステートメントに FOR UPDATE 文節が含まれている場合に、 エラー・メッセージ SQJ0204E を受け取ります。

解決方法

SELECT ステートメントから FOR UPDATE 文節を除去します。 イテレーター宣言文節で、更新可能イテレーターを指定します。 次に例を示します。

   #sql public iterator DelByName implements sqlj.runtime.ForUpdate(String EmpNo)
      with updateColumns = (salary);

どの列が更新可能かを明示的に識別したい場合には、 WITH 文節と共に updateColumns キーワードを使ってこれらを指定します。

位置指定されたイテレーター宣言について詳しくは、 アプリケーション開発の手引き を参照してください。

DB2 ユニバーサル・データベース バージョン 6 での文字名サイズ


WIN UNIX OS/2

変更点

DB2 ユニバーサル・データベース バージョン 6 は、128 バイトの表、視点、別名、 および 30 バイトの列名をサポートします。 以前のサポートは、それぞれのエンティティー名につき 18 バイトでした。

USER および CURRENT SCHEMA 特殊レジスターは CHAR(8) でしたが、 現在は VARCHAR(128) です。 CURRENT EXPLAIN MODE 特殊レジスターは CHAR(8) でしたが、現在は VARCHAR(254) です。 TYPE_SCHEMA および TABLE_SCHEMA 組み込み関数の出力は、 CHAR(8) でしたが、現在は VARCHAR(128) です。

症状

バージョン 6 より前に開発したアプリケーションが、 長さの制限を拡張していないバージョン 6 データベースに対して実行された場合、 アプリケーションの動作はまったく変わりません。 しかし、長い名前を使用する バージョン 6 の データベースに対してこれらのアプリケーションを実行すると、 これらのアプリケーションが作成された方法によっては、 何らかの副次作用が発生する可能性があります。

以下は、その例です。

解決方法

このタイプの問題を解決する最善の方法は、アプリケーションをコーディングしなおして、 より長い表および列名を処理できるようにすることです。 または、これらのアプリケーションが 18 バイトを超える名前を使用する バージョン 6 データベースに対して実行されないようにします。

DB2 ユニバーサル・データベース バージョン 6 での PC/IXF の形式変更


WIN UNIX OS/2

変更点

DB2 ユニバーサル・データベース バージョン 6 は、128 バイトの表、視点、別名、 および 30 バイトの列名をサポートします。 以前のサポートは、それぞれのエンティティー名につき 18 バイトでした。

症状

DB2 ユニバーサル・データベース バージョン 5 クライアントは、 DB2 ユニバーサル・データベース バージョン 6 クライアントによって エクスポートされた PC/IXF をインポートできません (エラー SQL3059N)。 また、(DB2 ユニバーサル・データベース バージョン 6 クライアントから エクスポートされた) PC/IXF ファイルは、 DB2 ユニバーサル・データベース バージョン 5 データベースにロードできません (エラー SQL3059N)。

解決方法

PC/IXF データをインポートまたはロードするときには、 互換性のある DB2 ユニバーサル・データベースのバージョンを使用します。

DB2 ユニバーサル・データベース バージョン 6 での非ダブル SQLVAR の SQLNAME


WIN UNIX OS/2

変更点

DB2 ユニバーサル・データベース バージョン 6 は、30 バイトの列名をサポートします。 以前のサポートは 18 バイトでした。 バージョン 5 で説明されている動作では、 非ダブルの SQLVAR の SQLNAME フィールドの 30 番目のバイトに "0xFF" が 入るようになっていました。しかし、システムの生成する名前、 および "AS" 文節でユーザーの指定した列名については、 30 番目のバイトに "0x00" が入ります。

バージョン 6 では、システムが生成した名前の場合にのみ、 30 番目のバイトに "0xFF" が戻されます。

症状

ユーザー指定の名前かシステム生成の名前かを判別する ために SQLNAME フィールドの 30 番目のバイトを調べるアプリケーションでは、 ユーザー指定の列名の長さが 30 文字の場合、 予期しない論理チェックを受け取る可能性があります。 これは、めったに起きません。

解決方法

SQLNAME フィールドの長さが 30 バイトより短い場合には、 これらのアプリケーションを変更して、 SQLNAME フィールドの 30 番目のバイトで "0xFF" の検査だけを実行するようにできます。 この場合、名前はユーザー生成の名前になります。

DB2 ユニバーサル・データベース バージョン 6 で使用されなくなった DB2 CLI/ODBC 構成キーワード


WIN

変更点

DB2 UDB の新しいバージョンに移行する際に、 db2cli.ini ファイルで一連の任意選択キーワードを指定して、 DB2 CLI/ODBC ドライバーの動作を変更することができます。

バージョン 6 では、TRANSLATEDLL および TRANSLATEOPTION キーワードは廃止されました。

症状

これらのキーワードは、存在していても無視されます。 これらの設定値が除去されたために、動作が変わる場合があります。

解決方法

有効なパラメーターの最新のリストを調べて、 自分の環境にとって適切なキーワードと設定値を決定してください。 これらのキーワードについては、コール・レベル・インターフェースの手引きおよび解説書 を参照してください。

DB2 ユニバーサル・データベース バージョン 6 でのイベント・モニターの出力ストリーム形式


WIN UNIX OS/2

変更点

イベント・モニターの出力ストリームには、バージョン管理がありません。 結果として、18 バイトより大きい表名のサポートを追加すると、 出力ストリーム形式への移行が必要になります。

症状

イベント・モニターの出力ストリームを解析するアプリケーションは、 正しく機能しなくなります。

解決方法

以下の 2 つから選択できます。

SQL

DB2 ユニバーサル・データベース バージョン 6 での DATALINK 列



UNIX

変更点

DB2 ユニバーサル・データベース バージョン 6 に挿入される DATALINK 値には、 列値記述子に 4 バイトのスペースが余分に必要になります。

症状

バージョン 5.2 で作成された DATALINK 列を更新するとき、 新しい列値を保管するためにデータ・ページに 4 バイト追加する必要があります。 結果として、この更新を完了するのに必要なスペースがデータ・ページにないために、 これが新しいページに移動される可能性があります。 このために、更新によってスペースが使い尽くされてしまいます。

解決方法

更新できるように、システムにさらにスペースを追加する必要があります。

DB2 ユニバーサル・データベース バージョン 6 での SYSFUN ストリング関数シグニチャー


WIN UNIX OS/2

変更点

SYSFUN スキーマにある多くのストリング関数には、 SYSIBM スキーマ (組み込み関数) で定義された改良済みのバージョンがあります。 関数名は、LCASE、LTRIM、RTRIM、および UCASE です。

症状

ステートメントを準備したり視点を作成する際には、 これらの関数のいずれかから戻されるデータ・タイプが、 バージョン 6 では異なっている可能性があります。 これが発生する原因は、(SYSIBM スキーマにある) 組み込み関数が通常、 SYSFUN スキーマにある関数が解決されるよりも前に解決されるためです。

解決方法

処置は必要ありません。 通常、組み込み関数は SYSFUN スキーマにある関数よりも優先的に使用されます。 以前のバージョンの動作を復元するには、 (SYSFUN が SYSIBM に先行するように) SQL パスを切り替えます。 ただし、これによってパフォーマンスは低下します。 または、関数名をスキーマ名 SYSFUN で修飾することによって、 以前のバージョンの関数を呼び出すこともできます。

これらの関数を参照する移行済みのパッケージ、視点、要約表、 トリガー、および制約は、パッケージを明示的にバインドしたり、 視点、要約表、トリガー、または制約を作成しなおすなどの 明示的なアクションを実行しないかぎり、 SYSFUN スキーマからのバージョンを使用し続けます。

DB2 ユニバーサル・データベース バージョン 6 での新しい保全状態での SYSTABLE 列の変更


WIN UNIX OS/2

変更点

SET INTEGRITY ... OFF ステートメントが実行されるときの、 SYSCAT.TABLES の CONST_CHECKED 列にある "U" 状態の変化の仕方が変わりました。

症状

バージョン 6 よりも前は、 SET INTEGRITY ... OFF ステートメントが実行されるときに、 CONST_CHECKED 列の "U" 状態が "N" 状態に変化しました。 現在では、"U" 状態は "W" 状態に変化します。

解決方法

処置は必要ありません。 CONST_CHECKED 列の新しい "W" 状態を使用して、 制約タイプが以前にユーザーによって検査されたこと、 および表にある一部のデータは保全性の検査をする必要があることを示します。

"N" 状態によって、データベース・マネージャーが検査していない古いデータが 存在するかどうかをはっきり確認することはできません。 これに続けて SET INTEGRITY ... IMMEDIATE CHECKED INCREMENTAL ステートメントが発行されると、 データベース・マネージャーは必ずエラーを戻します。これは、 新しい変更のみが検査されたためデータ保全性が保証できないからです。 一方、(INCREMENTAL オプションが指定されている場合に) "W" 状態を "U" 状態に戻して、 引き続きユーザーが表のデータの保全性を保つ責任があることを示すこともできます。 INCREMENTAL オプションが指定されていない場合には、 データベース・マネージャーは完全処理を選択し、 "W" 状態を "Y" 状態に変更して、データ保全を担当することを再び想定します。

データベースの機密保護と調整

DB2 ユニバーサル・データベース バージョン 6 でクライアントを使用してデータベースを作成する


WIN UNIX OS/2

変更点

データベースを作成するためにクライアントにより使用される方式。

症状

バック・レベルのクライアントを使用してデータベースを作成するとエラーが発生します。

解決方法

クライアントを使用してデータベースを作成する場合には、 クライアントとサーバーが同じレベルの DB2 コードを実行するようにします。

DB2 ユニバーサル・データベース バージョン 6 の階層で必要な SELECT 特権


WIN 32 ビット UNIX OS/2

変更点

(表に) ONLY キーワードを指定すると、ユーザーには、 指定されているタイプ付き表のすべての副表に対する SELECT 特権が必要になりました。 同様に、(視点に) ONLY キーワードを指定すると、ユーザーには、 指定されているタイプ付き表のすべての副視点に対する SELECT 特権が必要になりました。 以前のバージョンの DB2 では、 指定された表または視点のみの SELECT 特権が必要でした。

症状

症状として起こる可能性があるのは、以下の 2 つです。

解決方法

パッケージの再バインドや新しい視点およびトリガーの作成に必要な許可 ID に、 ONLY キーワードに続いて指定された表 (および視点) のすべての副表 (および 副視点) に対する SELECT 特権を与える必要があります。

DB2 ユニバーサル・データベース バージョン 6 で使用されなくなったプロファイル登録変数および環境変数


WIN UNIX OS/2

変更点

以下のプロファイル・レジストリーまたは環境変数は使用されなくなりました。

解決方法

これらの変数は必要でなくなりました。

ユーティリティーとツール

DB2 ユニバーサル・データベース バージョン 6 での現行の Explain モード


WIN UNIX OS/2

変更点

"CURRENT EXPLAIN MODE" 特殊レジスターのタイプは、 CHAR(8) から VARCHAR(254) に変更されました。

症状

アプリケーションがタイプを CHAR(8) のままと想定している場合には、 値が 254 バイトから 8 バイトに切り捨てられる可能性があります。

解決方法

特殊レジスターを読み取るすべてのホスト変数のタイプを、 CHAR(8) から VARCHAR(254) に再定義します。

この変更は、"CURRENT EXPLAIN MODE" 特殊レジスターの 2 つの新しい値を使用できるようにするために必要です。 新しい値は "EVALUATE INDEXES" および "RECOMMEND INDEXES" です。

DB2 ユニバーサル・データベース バージョン 6 での USING および SORT BUFFER パラメーター


WIN UNIX OS/2

変更点

バージョン 6 では、LOAD コマンドの USING および SORT BUFFER パラメーターは サポートされなくなりました。 これらのパラメーターは無視されます。

症状

パラメーター USING および SORT BUFFER はもはやサポートされず、 ロード・ユーティリティーはこれらを無視するという警告メッセージが戻されます。

解決方法

警告メッセージを無視します。 詳細については、データ移動ユーティリティー 手引きおよび解説書 を参照してください。

接続性と共存

DB2 ユニバーサル・データベース バージョン 6 での RUMBA から PCOMM への置換


WIN

変更点

バージョン 6 において、Windows NT、Windows 98、 および Windows 95 では RUMBA が PCOMM に置換されました (Windows 3.1 では RUMBA のままです)。

症状

なし。

解決方法

なし。

構成パラメーター

使用されなくなったデータベース構成パラメーター


WIN UNIX OS/2

変更点

以下のデータベース構成パラメーターは、使用されなくなりました。

解決方法

アプリケーションから、これらのパラメーターの参照をすべて除去します。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]