|以下を『マルチスレッド・ミックス・アプリケーション』セクションの終わりに追加します。
以下は、この章の新しいセクションです。
DB2 CLI ユニコード・アプリケーションのサポート領域には次の 2 つがあります。
以下のセクションは、これらの領域の両方についての詳細を提供します。ユニコード・アプリケーションと認識されるためには、アプリケーションは接続を行う前に、 SQL_ATTR_ANSI_APP 接続属性を SQL_AA_FALSE に設定する必要があります。これを行うと、 CLI は、データベースとの希望する連絡方法として、必ずユニコードを使用します。
ODBC API 関数には、ストリング引き数の形式を示す接尾部があります。ユニコードを受け入れる関数の接尾部は W で終わります。 ANSI を受け入れる関数には接尾部は付きません。
SQLBrowseConnect SQLForeignKeys SQLPrimaryKeys SQLColAttribute SQLGetConnectAttr SQLProcedureColumns SQLColAttributes SQLGetConnectOption SQLProcedures SQLColumnPrivileges SQLGetCursorName SQLSetConnectAttr SQLColumns SQLGetDescField SQLSetConnectOption SQLConnect SQLGetDescRec SQLSetCursorName SQLDataSources SQLGetDiagField SQLSetDescField SQLDescribeCol SQLGetDiagRec SQLSetStmtAttr SQLDriverConnect SQLGetInfo SQLSpecialColumns SQLGetStmtAttr SQLStatistics SQLError SQLNativeSQL SQLTablePrivileges SQLExecDirect SQLPrepare SQLTables
引き数が常にストリングの長さであるユニコード関数は、この引き数を文字数として解釈します。サーバー・データに対して長さの情報を返す関数は、表示サイズと精度を文字数で示します。長さ (データの転送サイズ) がストリングまたは非ストリングのデータを参照するときは、長さはバイト数として解釈されます。例えば、SQLGetInfoW は長さをバイト数として取りますが、SQLExecDirectW は文字数を使用します。CLI は、結果セットからのデータを、アプリケーションのバインドに応じて、ユニコードまたは ANSI で返します。アプリケーションが SQL_C_CHAR にバインドする場合、ドライバーは SQL_WCHAR データを SQL_CHAR に変換します。ODBC ドライバー・マネージャー (使用する場合) は、 ANSI ドライバーについては SQL_C_WCHAR を SQL_C_CHAR にマップしますが、ユニコード・ドライバーについてはマッピングを行いません。
|追加の ODBC および CLI 定義のデータ・タイプが、ユニコード・データベースに |適応させるために追加されました。 |これらのタイプは既存の C タイプおよび SQL タイプのセットを補足します。新しい C タイプ、SQL_C_WCHAR は、 |C バッファーにネイティブ・エンディアン形式の UCS-2 データが含まれていることを指示します。新しい SQL タイプ |の SQL_WCHAR、SQL_WVARCHAR、および SQL_WLONGVARCHAR は、特定の列またはパラメーター・マーカーに |ユニコード・データが含まれていることを示します。 |DB2 ユニコード・データベースの場合、グラフィック列は新規のタイプを使用して |記述されます。
|
SQL データ・ タイプ |
S Q L _ C _ C H A R |
S Q L _ C _ W C H A R |
S Q L _ C _ L O N G |
S Q L _ C _ S H O R T |
S Q L _ C _ T I N Y I N T |
S Q L _ C _ F L O A T |
S Q L _ C _ D O U B L E |
S Q L _ C _ T Y P E _ D A T E |
S Q L _ C _ T Y P E _ T I M E |
S Q L _ C _ T Y P E _ T I M E S T A M P |
S Q L _ C _ B I N A R Y |
S Q L _ C _ B I T |
S Q L _ C _ D B C H A R |
S Q L _ C _ C L O B _ L O C A T O R |
S Q L _ C _ B L O B _ L O C A T O R |
S Q L _ C _ D B C L O B _ L O C A T O R |
S Q L _ C _ B I G I N T |
S Q L _ C _ N U M E R I C |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
BLOB |
X |
X |
|
|
|
|
|
|
|
|
D |
|
|
|
X | |||
|
CHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X | |
|
CLOB |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
X |
| |||
|
DATE |
X |
X |
|
|
|
|
|
D |
|
X |
|
|
|
|
| |||
|
DBCLOB |
|
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
X | ||
|
DECIMAL |
D |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
X |
X | |
|
DOUBLE |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
X |
X | |
|
FLOAT |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
X |
X | |
|
GRAPHIC (非ユニコード) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
| |||
|
GRAPHIC (ユニコード) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
|
INTEGER |
X |
X |
D |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
X |
X | |
|
LONG VARCHAR |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
|
| |||
|
LONG VARGRAPHIC (非ユニコード) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
| |||
|
LONG VARGRAPHIC (ユニコード) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
|
|
|
|
NUMERIC |
D |
X |
X |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
X | ||
|
REAL |
X |
X |
X |
X |
X |
D |
X |
|
|
|
|
X |
|
|
|
X | ||
|
SMALLINT |
X |
X |
X |
D |
X |
X |
X |
|
|
|
|
X |
|
|
|
X |
X | |
|
BIGINT |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
D |
X | |
|
TIME |
X |
X |
|
|
|
|
|
|
D |
X |
|
|
|
|
| |||
|
TIMESTAMP |
X |
X |
|
|
|
|
|
X |
X |
D |
|
|
|
|
| |||
|
VARCHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X | |
|
VARGRAPHIC (非ユニコード) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
| |||
|
VARGRAPHIC (ユニコード) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
ユニコード・アプリケーションがサポートされるようになるまでは、GRAPHIC=1、2、または 3 や Patch2=7 といった一連の cli ini ファイル・キーワードによって、単一バイト文字データの操作用に作成されたアプリケーションが 2 バイト漢字データを操作できるようにしていました。これらの回避策では、漢字データを文字データとして表示しており、報告されるデータの長さにも影響が出ました。
|これらのキーワードは、ユニコード・アプリケーションの場合には不要であり、 |さらに潜在的な副作用を持つ危険性があるため、使用しないようにしてください。あるアプリケーションがユニコード・ |アプリケーションかどうかがわからない場合は、漢字データの処理に影響する |キーワードなしで試してみることをお勧めします。
非ユニコード・データベースでは、LONG VARGRAPHIC および LONG VARCHAR 列のデータは比較できません。 GRAPHIC/VARGRAPHIC および CHAR/VARCHAR 列のデータは、比較のみが可能か、または暗黙的コード・ページ変換がサポートされていないため、明示的な cast 関数を使用して相互に割り当てることができます。これには、GRAPHIC/VARGRAPHIC リテラルが G 接頭部によって CHAR/VARCHAR と区別される、GRAPHIC/VARGRAPHIC および CHAR/VARCHAR が含まれます。
ユニコード・データベースについては、GRAPHIC/VARGRAPHIC および CHAR/VARCHAR リテラル間のキャストは不要です。また、G 接頭部は GRAPHIC/VARGRAPHIC リテラルの前には必要ありません。少なくとも 1 つの引き数がリテラルの場合、暗黙的変換が行われます。これにより、リテラルは G 接頭部を持っていても持っていなくても、 SQLPrepareW() または SQLExecDirect() を使用するステートメント内で使用することができます。LONG VARGRAPHIC のリテラルには G 接頭部が必要です。
詳しくは、「SQL 解説書」の『第 3 章 言語エレメント』の『データ・タイプ間のキャスト』を参照してください。
ユニコード・アプリケーションがデータベースに接続するときに余分なオーバーヘッドを避けるために、次の 3 つのキーワードが追加されました。
ユニコード・サポートが使用可能になっている場合、ユニコード・アプリケーションから呼び出されると、CLI はコード・ページ変換による不要なデータ喪失のないように、最適なクライアント・コード・ページを使用してデータベースに接続しようとします。そのために、コード・ページ交換のために接続時間が増加するか、またはこのサポートが追加されるまでは行われていなかったクライアントでのコード・ページ変換が行われる可能性があります。
このキーワードを true (1) に設定すると、すべてのユニコード・データは最初に (サーバーに送信される前に) アプリケーションのローカル・コード・ページに変換されます。このことが原因で、ローカル・コード・ページでは表示できないデータが失われることがあります。
非ユニコード・アプリケーションは、データベースへの接続時には常にそのアプリケーションのローカル・コード・ページか DB2Codepage 環境設定を使用します。デフォルトでは、CLI により、ユニコード・アプリケーションはユニコード・データベースへの接続時には常に UTF-8 および UCS-2 コード・ページを使用します。非ユニコード・データベースへの接続時のデフォルトでは、データベース・サーバーが DB2 (Windows 版)、DB2 (Unix 版)、または DB2 (OS/2 版) を実行している場合、そのデータベースのコード・ページを使用します。これにより、コード・ページ変換に起因した不必要なデータ喪失がなくなります。
このキーワードを使用すれば、非ユニコード・データベースに接続するときにはそのデータベースのコード・ページを指定して、接続時に余分なオーバーヘッドが生じないようにできます。
値 1 を指定すると、SQLDriverConnect() は出力接続ストリングに正しい値を返します。これによりこの値を以降の SQLDriverConnect() 呼び出しで使用することが可能となります。
このキーワードは ConnectCodepage=1208 と同じもので、便宜上追加されたものです。 DB2 (OS/390 版) バージョン 7 またはそれ以降に接続するときの余分な接続オーバーヘッドを避けるためにこのキーワードを設定してください。DB2 (Windows 版)、DB2 (Unix 版)、または DB2 (OS/2 版) については、余分な処理が必要にならないため、このキーワードを設定する必要はありません。
|『インストールおよび構成』サブセクションに記載されている DISABLEMULTITHREAD 構成キーワードの |デフォルト値は、次のように訂正されます。 |
以下の情報は『スクロール可能カーソル』セクションに追加されています。
Unix、Windows、および OS/2 プラットフォームの UDB クライアントは、 OS/390 バージョン 7 データベースに対して実行される際、更新可能なサーバー側のスクロール可能カーソルをサポートします。 3 階層環境で OS/390 スクロール可能カーソルにアクセスするには、クライアントおよびゲートウェイが DB2 UDB バージョン 7.1 フィックスパック 3 以降を実行している必要があります。
スクロール可能カーソルにアクセスできるアプリケーション使用可能化インターフェースには、 ODBC と JDBC の 2 つがあります。 JDBC インターフェースは、静的スクロール可能カーソルにのみアクセスすることが可能で、 ODBC インターフェースは、静的およびキーセット・ドリブンのサーバー側スクロール可能カーソルにアクセスすることが可能です。
下の表では、ODBC での OS/390 バージョン 7 カーソルのデフォルト属性をリストします。
表 12. ODBC での OS/390 カーソルの デフォルト属性
| カーソル・タイプ | カーソル感度 | カーソル更新可能 | カーソル並列性 | カーソル・スクロール可能 |
|---|---|---|---|---|
| フォワードのみ a | 未指定 | 更新不可 | 読み取り専用並列性 | スクロール不可 |
| 静的 | 反映不可 | 更新不可 | 読み取り専用並列性 | スクロール可能 |
| キーセット・ドリブン | 反映可能 | 更新可能 | 値並列性 | スクロール可能 |
|
| ||||
すべての ODBC フェッチ方向が SQLFetchScroll または SQLExtendedFetch インターフェースでサポートされます。
キーセット・ドリブン・カーソルは更新可能なカーソルです。照会が SELECT ... FOR READ ONLY として実行されている場合、または FOR UPDATE 文節がすでに指定されている場合を除いて、CLI ドライバーは FOR UPDATE 文節を照会に追加します。 DB2 (OS/390 版) に実装されたキーセット・ドリブン・カーソルは、値並列性カーソルです。値並列性カーソルを使用するとオプティミスティック・ロックになります。更新または削除が試行されるまでロックは行われません。更新または削除が試行されると、データベース・サーバーは、アプリケーションが検索した以前の値を基礎表の現行値と比較します。値が一致する場合、更新または削除は成功します。値が一致しない場合、操作は失敗します。失敗した場合、アプリケーションは値をもう一度照会して、まだ適用可能であれば更新または削除を再実行します。
アプリケーションはキーセット・ドリブン・カーソルを以下の 2 つの方法で更新することができます。
スクロール可能カーソル・サポートは新しい機能であるため、 UDB (OS/390 版) または UDB (Unix 版、Windows 版、および OS/2 版) の前のリリースを使用していた一部の ODBC アプリケーションでは、振る舞いまたはパフォーマンスが変わる可能性があります。スクロール可能カーソルを要求したアプリケーションは、スクロール可能カーソルがサポートされる前はフォワードのみカーソルを受け取っていたために、このようなことが起こります。スクロール可能カーソル・サポート前のアプリケーションの振る舞いをリストアするには、次の構成キーワードを db2cli.ini ファイルに設定します。
表 13. スクロール可能カーソル・サポート前のアプリケーションの振る舞いをリストアする 構成キーワード値
| 構成キーワード設定 | 説明 |
|---|---|
| PATCH2=6 | スクロール可能カーソル (キーセット・ドリブンおよび静的) がサポートされていないというメッセージを返します。CLI は、スクロール可能カーソルの要求をフォワードのみカーソルに自動的にダウングレードします。 |
| DisableKeysetCursor=1 | サーバー側とクライアント側の両方のキーセット・ドリブン・スクロール可能カーソルを使用不可にします。これは、キーセット・ドリブン・カーソルが要求されたときに、CLI ドライバーによってアプリケーションが静的カーソルを提供することを強制するために使用されます。 |
| UseServerKeysetCursor=0 | クライアント側のキーセット・ドリブン・カーソル・ライブラリーを使用してキーセット・ドリブン・カーソルをシミュレートするアプリケーションに対してサーバー側のキーセット・ドリブン・カーソルを使用不可にします。サーバー側のキーセット・ドリブン・カーソルで問題が発生した場合のみ、このオプションを使用します。クライアント側のカーソルは大量のオーバーヘッドを発生させ、通常、サーバー側のカーソルよりパフォーマンスが劣ってしまうためです。 |
以下の注釈がブックから欠落しています。
照会以外の動的に準備できる SQL ステートメントは、 複合ステートメント内のステートメントとして実行可能です。 注: アトミック複合 SQL 内では、保管点、リリース保管点、および 保管点 SQL ステートメントへのロールバックも否認されます。逆に、 アトミック複合 SQL は保管点で否認されます。
|次の特権を SQL ストアード・プロシージャーを作成、デバッグ、実行するユーザーに |認可する必要があります。 |
|次の特権を Java ストアード・プロシージャーを作成、デバッグ、実行するユーザーに |認可する必要があります。 |
|DB2DBG.ROUTINE_DEBUG 表を作成するには、次のコマンドを実行してください。
|db2 -tf sqllib/misc/db2debug.ddl
|Java ストアード・プロシージャーについて詳しくは、「アプリケーション開発の手引き」を参照してください。
以下は、CLI ストアード・プロシージャーに対する文書化されていない制限です。
複数 CLI ストアード・プロシージャーへの呼び出しを行う場合、 次のストアード・プロシージャーを呼び出す前に、アプリケーションは ストアード・プロシージャーからオープン・カーソルをクローズする 必要があります。具体的には、オープン・カーソルの最初のセットを、 次のストアード・プロシージャーがカーソルをオープンしようとする前に クローズしなければなりません。
以下は、ブックの補足情報です。
CLI/ODBC ドライバーは、CLI/ODBC アプリケーションが、データベースに対して SQL を初めて実行した時に、ユーザーに適切な特権または許可がある場合、CLI パッケージを自動バインドします。CLI パッケージの自動バインドは、ストアード・プロシージャー内から実行できません。そのため、アプリケーションが最初に行うことが CLI ストアード・プロシージャーの呼び出しである場合、この自動バインドは起きません。新しい DB2 データベースに対して CLI ストアード・プロシージャーを呼び出す CLI アプリケーションを実行する前に、次のコマンドで、一度 CLI パッケージをバインドする必要があります。
db2 bind <BNDPATH>/@db2cli.lst blocking all
db2bind "%DB2PATH%¥bnd¥@db2cli.lst" blocking
お勧めするアプローチとしては、実行時に自動バインドするのを回避するために、データベースが、作成される時に、このパッケージを常にバインドする方法があります。自動バインドは、ユーザーに特権がない場合、または別のアプリケーションが同時に自動バインドを行っている場合には失敗します。