以下の節が含まれています。
バージョン 2 にあってバージョン 5 では使用すべきでないとされた各 DB2 CLI 関数は、現在も関数参照にリストされています。それぞれの関数についての説明の冒頭に、その旨が示されています。
DB2 CLI バージョン 5 では、使用すべきでない関数も引き続きすべてサポートしていますが、最新の標準に合わせて、新しい関数を DB2 CLI プログラムでご使用になることをお勧めします。
ものによっては、使用すべきでない関数の機能および引き数と、それに代わる関数が酷似している場合があります (たとえば、SQLColAttributes() と SQLColAttribute() など)。そのような場合、使用すべきでない関数の説明は省かれています。
また、別の場合には、使用すべきでない関数の説明がそのままになっているものもあり、その場合、新しい関数に切り替えになったことを理解する助けとなります。
下記の表には、使用すべきでない関数とその説明、および代わりの関数がそれぞれリストされています。
使用すべきでない関数 | 説明 | 代わりの関数 |
---|---|---|
SQLAllocConnect() | 除去 | SQLAllocHandle() |
SQLAllocEnv() | 除去 | SQLAllocHandle() |
SQLAllocStmt() | 除去 | SQLAllocHandle() |
SQLColAttributes() | 除去 | SQLColAttribute() |
SQLError() | 変更なし | SQLGetDiagField() および SQLGetDiagRec() |
SQLExtendedFetch() | 変更なし | SQLFetchScroll() |
SQLFreeConnect() | 変更なし | SQLFreeHandle() |
SQLFreeEnv() | 変更なし | SQLFreeHandle() |
SQLGetConnectOption() | 除去 | SQLGetConnectAttr() |
SQLGetStmtOption() | 除去 | SQLGetStmtAttr() |
SQLParamOptions() | 変更なし | SQLSetStmtAttr() |
SQLSetConnectOption() | 除去 | SQLSetConnectAttr() |
SQLSetParam() | 除去 | SQLBindParameter() |
SQLSetStmtOption() | 除去 | SQLSetStmtAttr() |
SQLTransact() | 変更なし | SQLEndTran() |
DB2 ユニバーサル・データベース バージョン 5 では、サーバーの全ストアード・プロシージャーに関する情報を保管するための 2 つのシステム・カタログ表示を導入しています。バージョン 5 以前では、DB2 CLI はストアード・プロシージャー登録の疑似カタログ表を使用していました。デフォルトで、DB2 CLI は新しいシステム・カタログ表示を使用することになります。アプリケーションで疑似カタログ表の使用が見込まれる場合、 CLI/ODBC 構成キーワード PATCH1 を 262144 に設定してください。
バージョン 2 DB2 共通サーバーへのアプリケーションの接続時に、 SQLProcedureColumns() および SQLProcedures() がストアード・プロシージャーの情報を (疑似カタログ表から) 戻せるように、ストアード・プロシージャー登録の疑似カタログ表がすでに作成され、満たされている必要があります。これは DB2CLI スキーマにおける PROCEDURES という名前のついた表です。この疑似カタログ表の詳細は、付録 H, ストアード・プロシージャー登録の疑似カタログ表を参照してください。この表を満たす際、付録 H, ストアード・プロシージャー登録の疑似カタログ表にある規則どおりに行うことが肝要であり、そうしないと SQLProcedureColumns() および SQLProcedures() 呼び出しはエラーになります (SQLSTATE 42601)。
SQLSetConnectAttr() 関数は、ステートメント属性のサブセットを設定する場合にのみ使用できます。この関数はまもなく廃止になり、新しい DB2 CLI ではこの機能を使いません。バージョン 5 以前の DB2 CLI では、SQLSetConnectOption() を使用してこの機能を使っていましたが、その後除去されて、関数も使用すべきでないものとされています。
バージョン 5 以前に書かれた DB2 CLI アプリケーションをサポートするため、現在 SQLSetConnectAttr() は、バージョン 2 で定義された以下のオプション値を使用して、以前の SQLSetConnectOption() と同様の働きをしています。 (バージョン 5 では '_ATTR_' が追加になっています。)
DB2 の前のバージョンには、グローバル・ステートメント・キャッシュがありませんでした。しかし、サーバーで動的ステートメント・キャッシュ を提供していました。 DB2 CLI でこのことは、あるステートメント・ハンドルについて、ステートメントが一度準備されると、そのステートメント・ハンドルが解放される場合を除いて再度準備する必要がないことを意味します (コミットやロールバックの後も同様)。複数のトランザクションで同一の SQL ステートメントを繰り返し実行するアプリケーションの場合、次のことを実行すると、処理時間とネットワーク通信量を相当量節約できます。
DB2 ユニバーサル・データベースのバージョン 5 では、グローバル動的ステートメント・キャッシュがあるため、これが不要になりました。最初のステートメントを準備すると、グローバル・キャッシュにパッケージが作成されます。それ以降の準備要求は、いずれもキャッシュの中から最初のアクセス・プランを見つけて、すぐに使用します。
トランザクション境界間の動的ステートメント・キャッシュをサポートしないサーバーにアプリケーションが接続すると、 DB2 CLI は必要に応じて各ステートメントを内部的に準備します。このことは、RDBMS とは関係なくすべてのアプリケーションについて上記の方式を使用できることを意味します。
次の表は、SQLColumns() によって戻される列への変更を、バージョン 2.1.1 とバージョン 5 で対比したリストです。
現在の値については、『SQLColumns() で戻される列』を参照してください。
DB2 CLI をバージョン 2 の場合と同じように (同じ列名および順序で) 動作させるには、
DB2 CLI/ODBC 構成キーワード PATCH2 を設定します。このキーワード設定について、詳しくは CLI/ODBC 構成キーワードの設定方法を参照してください。
バージョン 2 の列 | バージョン 5 の列 | 変更 |
---|---|---|
14 DATETIME_CODE | バージョン 5 では除去 | この情報は戻されなくなった。バージョン 2 では常に NULL だった。 |
バージョン 2 と同等のものはない。 | 14 SQL_DATA_TYPE | この情報はバージョン 2 では戻されなかった。 |
バージョン 2 と同等のものはない。 | 15 SQL_DATETIME_SUB | この情報はバージョン 2 では戻されなかった。 |
15 CHAR_OCTET_LENGTH | 16 CHAR_OCTET_LENGTH | 列番号が変更。名前と説明は変更なし。 |
16 ORDINAL_POSITION | 17 ORDINAL_POSITION | 列番号が変更。名前と説明は変更なし。 |
17 IS_NULLABLE | 18 IS_NULLABLE | 列番号が変更。名前と説明は変更なし。 |
次の表は、SQLProcedureColumns() によって戻される列への変更を、バージョン 2.1.1 とバージョン 5 で対比したリストです。
現在の値については、『SQLProcedureColumns で戻される列』を参照してください。
DB2 CLI をバージョン 2 の場合と同じように (同じ列名および順序で) 動作させるには、
DB2 CLI/ODBC 構成キーワード PATCH2 を設定します。このキーワード設定について、詳しくは CLI/ODBC 構成キーワードの設定方法を参照してください。
表 185. SQLProcedureColumns で戻される列の変更
バージョン 2 の列 | バージョン 5 の列 | 変更 |
---|---|---|
14 ORDINAL_POSITION | 18 ORDINAL_POSITION | 列番号が変更。名前と説明は変更なし。 |
新しい InfoTypes を多数 SQLGetInfo() に追加しただけでなく、以下のバージョン 2 の値がバージョン 5 では名前変更されています。
バージョン 2 の InfoType | バージョン 5 の InfoType |
---|---|
SQL_ACTIVE_CONNECTIONS | SQL_MAX_DRIVER_CONNECTIONS |
SQL_ACTIVE_STATEMENTS | SQL_MAX_CONCURRENT_ACTIVITIES |
SQL_MAX_OWNER_NAME_LEN | SQL_MAX_SCHEMA_NAME_LEN |
SQL_MAX_QUALIFIER_NAME_LEN | SQL_MAX_CATALOG_NAME_LEN |
SQL_ODBC_SQL_OPT_IEF | SQL_INTEGRITY |
SQL_SCHEMA_TERM | SQL_OWNER_TERM |
SQL_OWNER_USAGE | SQL_SCHEMA_USAGE |
SQL_QUALIFIER_LOCATION | SQL_CATALOG_LOCATION |
SQL_QUALIFIER_NAME_SEPARATOR | SQL_CATALOG_NAME_SEPARATOR |
SQL_QUALIFIER_TERM | SQL_CATALOG_TERM |
SQL_QUALIFIER_USAGE | SQL_CATALOG_USAGE |
DB2 CLI バージョン 5 では、デフォルトで据え置き準備がオンになります。対応する実行要求が発行されるまで、PREPARE 要求はサーバーに送られません。それから、2 つの要求は、ネットワーク・フローを最小化し、パフォーマンスを改善するために、 (2 つではなく) 1 つのコマンド / 応答フローに結合されます。これが最大の益となるのは、アプリケーションが照会を生成して応答のセットが非常に少ない場合や、別々の要求と回答のオーバーヘッドが照会データの複数ブロックに広がっていない場合です。 DB2 コネクト接続や DDCS ゲートウェイを使用する環境では、要求と回答の 4 つの組み合わせが 2 つに減るため、コスト削減の機会ともなります。
要求次第 PREPARE が実行されることを期待する DB2 CLI バージョン 2 アプリケーションでは、期待どおりの操作にならないことがあります。 (アプリケーションは、たとえば、通常は準備ステートメントの SQLCA の SQLERRD(3) と SQLERRD(4) に戻される行およびコスト見積もりに依存しますが、据え置き準備を使用可能にすると、これらの値はゼロになることがあります。) このようなプログラムに、バージョン 2 におけるのと同様の働きをさせるには、 DB2 CLI/ODBC 構成キーワード DEFERREDPREPARE を設定して、据え置き準備を使用不能にします。詳しくは DEFERREDPREPARE を参照してください。
また、ステートメント属性 SQL_ATTR_DEFERRED_PREPARE を使用して、それが発行されたならただちに DB2 CLI がステートメントを準備するようにすることもできます。詳しくは、SQLSetStmtAttr - ステートメントに関連したオプションの設定を参照してください。
バージョン 2 では、DB2 CLI アプリケーションは、関数 SQLSetColAttributes() を使用し、結果セットのすべての列に結果記述子情報を記述することによって、ネットワーク通信量を減らすことができました。据え置き準備では、この方法は無駄です。また、 SQLSetColAttributes() は使用すべきでない関数になっています。アプリケーションがこの関数を呼び出すと、すべての引き数が無視されることになり、必ず SQL_SUCCESS が戻されます。