DB2 10.5 for Linux, UNIX, and Windows

IBM Data Server Driver for JDBC and SQLJ のバージョン間での JDBC の相違点

JDBC アプリケーションを古いドライバーから IBM® Data Server Driver for JDBC and SQLJ の新しいバージョンにアップグレードする前に、それらのドライバー間の相違点を理解する必要があります。

サポートされるメソッド

IBM Data Server Driver for JDBC and SQLJ がサポートするメソッドのリストについては、JDBC API でのドライバーのサポートに関する情報を参照してください。

JDBC ドライバーによる連続ストリーミングの使用

IBM Data Server Driver for JDBC and SQLJ バージョン 3.50 以降の場合、連続ストリーミング (動的データ形式ともいう) の動作は、DB2® for Linux, UNIX, and Windows バージョン 9.5 以降への接続の場合の LOB 検索のデフォルトです。

連続ストリーミングは IBM Data Server Driver for JDBC and SQLJ バージョン 3.1 以降でサポートされています。 ただし、IBM Data Server Driver for JDBC and SQLJ バージョン 3.2 以降では、連続ストリーミングの動作は、DB2 for z/OS® バージョン 9.1 以降への接続の場合の LOB および XML 検索のデフォルトです。

IBM Data Server Driver for JDBC and SQLJ の以前のバージョンは、連続ストリーミングをサポートしません。

重要: 連続ストリーミングでは、LOB または XML の値を ResultSet からアプリケーション変数に取り出す場合、カーソルを移動するまで、または ResultSet 上のカーソルをクローズするまでは、そのアプリケーション変数の内容を操作できます。 その後は、アプリケーション変数の内容は操作できなくなります。 アプリケーション変数内の LOB に対して何らかのアクションを実行すると、SQLException を受け取ります。 例えば、連続ストリーミングが有効で、以下のようなステートメントを実行するとします。
… 
ResultSet rs = stmt.executeQuery("SELECT CLOBCOL FROM MY_TABLE");
rs.next();                // Retrieve the first row of the ResultSet 
Clob clobFromRow1  = rs.getClob(1); 
                          // Put the CLOB from the first column of
                          // the first row in an application variable
String substr1Clob = clobFromRow1.getSubString(1,50);
                          // Retrieve the first 50 bytes of the CLOB
rs.next();                // Move the cursor to the next row.
                          // clobFromRow1 is no longer available.
// String substr2Clob = clobFromRow1.getSubString(51,100);
                          // This statement would yield an SQLException
Clob clobFromRow2  = rs.getClob(1); 
                          // Put the CLOB from the first column of 
                          // the second row in an application variable
rs.close();               // Close the ResultSet. 
                          // clobFromRow2 is also no longer available.
rs.next() を実行してカーソルを ResultSet の 2 番目の行に置いた後は、clobFromRow1 内の CLOB 値は使用できなくなります。 同様に、rs.close() を実行して ResultSet をクローズした後、clobFromRow1 および clobFromRow2 内の値は使用できなくなります。

この動作の変更によるエラーを避けるには、以下のアクションのいずれかをとる必要があります。

IBM Data Server Driver for JDBC and SQLJ の ResultSetMetaData の値

IBM Data Server Driver for JDBC and SQLJ バージョン 4.0 以降の場合、ResultSetMetaData.getColumnName および ResultSetMetaData.getColumnLabel のデフォルトの動作は、それ以前の JDBC ドライバーのデフォルトの動作とは異なります。

IBM Data Server Driver for JDBC and SQLJ バージョン 4.0 以降を使用する必要があるが、アプリケーションが旧バージョンの JDBC ドライバーで戻された ResultSetMetaData.getColumnName および ResultSetMetaData.getColumnLabel の値を戻す必要がある場合、useJDBC4ColumnNameAndLabelSemantics Connection および DataSource プロパティーを DB2BaseDataSource.NO (2) に設定できます。

自動生成キーを使用したバッチ更新の結果はドライバーのバージョンによって異なる

IBM Data Server Driver for JDBC and SQLJ バージョン 3.52 以降では、自動生成キーの取り出し対応の SQL ステートメントを準備する機能がサポートされています。

IBM Data Server Driver for JDBC and SQLJ バージョン 3.50 またはバージョン 3.51 を使用する場合、SQL ステートメントを自動生成キーの取り出しのために準備し、バッチ更新に PreparedStatement オブジェクトを使用すると、SQLException が出されます。

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.50 より前のバージョンは、自動生成キーを戻すように準備された PreparedStatement オブジェクトに対してアプリケーションが addBatch または executeBatch メソッドを呼び出すときに、SQLException をスローしません。 ただし、PreparedStatement オブジェクトは自動生成キーを戻しません。

DB2 for z/OS サーバー上にあるデータのバッチ更新の結果はドライバーのバージョンによって異なる

executeBatch ステートメントを正常に呼び出すと、IBM Data Server Driver for JDBC and SQLJ によって配列が戻されます。 この配列の目的は、バッチで実行される各 SQL ステートメントによって影響を受ける行数を示すことです。

以下の条件が真の場合、IBM Data Server Driver for JDBC and SQLJ は配列エレメントで Statement.SUCCESS_NO_INFO (-2) を戻します。

これが生じるのは、複数行 INSERT を使用すると、データベース・サーバーがバッチ全体を 1 つの操作として実行するので、個々の SQL ステートメントの結果が戻されないためです。

旧バージョンの IBM Data Server Driver for JDBC and SQLJ を使用している場合、または DB2 for z/OS バージョン 8 より前のデータ・ソースに接続する場合、この配列エレメントには各 SQL ステートメントによって影響を受ける行数が含まれます。

DB2 for z/OS サーバー上のデータをバッチ更新/削除する場合のサイズ制限がドライバーのバージョンによって異なる

IBM Data Server Driver for JDBC and SQLJ バージョン 3.59 または 4.9 より前では、更新/削除バッチのサイズが 32KB より大きい場合、DB2 for z/OS への IBM Data Server Driver for JDBC and SQLJ タイプ 4 接続に関する DisconnectException (エラー・コード -4499) がスローされました。 バージョン 3.59 または 4.9 以降、この制限はもはや存在せず、例外はスローされなくなりました。

CURRENT CLIENT_ACCTNG 特殊レジスターの初期値

IBM Data Server Driver for JDBC and SQLJ バージョン 2.6 以降で実行される JDBC または SQLJ アプリケーションで、タイプ 4 接続が使用されている場合、DB2 for z/OS CURRENT CLIENT_ACCTNG 特殊レジスターの初期値は、DB2 for z/OS のバージョン番号と clientWorkStation プロパティーの値とを連結したものです。 JDBC ドライバー、バージョン、または接続のいずれかがそれとは異なる場合、初期値は設定されていません。

複数行 FETCH の使用を制御するプロパティー

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.7 およびバージョン 3.51 より前は、複数行 FETCH のサポートの有効および無効の制御は useRowsetCursor プロパティーで制御され、それは両方向スクロール・カーソルの場合にのみ使用可能であり、しかも DB2 for z/OS に対する IBM Data Server Driver for JDBC and SQLJ タイプ 4 接続 の場合にのみ利用可能でした。 バージョン 3.7 および 3.51 以降は、次のようになります。
  • DB2 for z/OS 上の IBM Data Server Driver for JDBC and SQLJ タイプ 2 接続 の場合、IBM Data Server Driver for JDBC and SQLJ において、両方向スクロールまたは前方スクロール・カーソルで複数行 FETCH を使用するかどうかを決めるのに、enableRowsetSupport プロパティーだけが使用されます。
  • DB2 for z/OS または DB2 for Linux, UNIX, and Windows に対する IBM Data Server Driver for JDBC and SQLJ タイプ 4 接続、または DB2 for Linux, UNIX, and Windows 上の IBM Data Server Driver for JDBC and SQLJ タイプ 2 接続 の場合、IBM Data Server Driver for JDBC and SQLJ では、enableRowsetSupport プロパティーが設定されているなら、両方向スクロール・カーソルで複数行 FETCH を使用するかどうかを決めるのにその enableRowsetSupport が使用されます。 enableRowsetSupport が設定されていない場合、ドライバーでは、useRowsetCursor プロパティーを使用することによって、複数行 FETCH を使用するかどうかが決定されます。

JDBC 1 位置指定の更新および削除と複数行 FETCH

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.7 およびバージョン 3.51 より前は、DB2 for z/OS の表からの複数行 FETCH は、useRowsetCursor プロパティーによって制御されていました。 アプリケーションに JDBC 1 位置指定更新または削除の操作が含まれていた場合、かつ複数行 FETCH サポートが有効であった場合、IBM Data Server Driver for JDBC and SQLJ では、その更新または削除の操作が許容されていましたが、その更新または削除で予期しない結果が発生することがありました。

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.7 および 3.51 以降では、DB2 for z/OS の表または DB2 for Linux, UNIX, and Windows の表からの複数行 FETCH が有効か無効かは、enableRowsetSupport プロパティーによって制御されます。 enableRowsetSupport プロパティーは、useRowsetCursor プロパティーをオーバーライドします。 enableRowsetSupport プロパティーによって複数行 FETCH が有効になっていて、アプリケーションに JDBC 1 位置指定の更新または削除の操作が含まれている場合、IBM Data Server Driver for JDBC and SQLJ により SQLException がスローされます。

DB2 for z/OS ビューから自動生成キーを取り出すための prepareStatement の有効な形式

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.57 またはバージョン 4.7 以降において、DB2 for z/OS データ・サーバー上でビューにデータを挿入する場合、自動生成キーを取り出すには、以下のメソッドのうちのいずれか 1 つを使用することにより、ビューに行を挿入する SQL ステートメントを準備する必要があります。

Connection.prepareStatement(sql-statement, String [] columnNames);
Connection.prepareStatement(sql-statement, int [] columnIndexes);
Statement.executeUpdate(sql-statement, String [] columnNames);
Statement.executeUpdate(sql-statement, int [] columnIndexes);

setString を使用する TIMESTAMP(p) 列の更新におけるデータ損失

setString 呼び出しを使って入力値を TIMESTAMP(p) 列に渡す場合、9 より大きい精度の値をその列に送ることができます。

バージョン 3.59 または 4.9 より前の IBM Data Server Driver for JDBC and SQLJ の場合、データ損失が生じる可能性があるのは sendDataAsIs プロパティーが false に設定され、入力値の精度が 9 より大きい場合です。

バージョン 3.59 および 4.9 以降の IBM Data Server Driver for JDBC and SQLJ の場合、入力値に対応できるほど十分な大きさが TIMESTAMP(p) 列にあればデータ損失は生じません。

java.sql.Timestamp 入力データの特殊な処理

バージョン 3.63 または 4.13 より前の IBM Data Server Driver for JDBC and SQLJ では、ターゲット・データ・タイプが不明であり、ターゲット・データ・サーバーが TIMESTAMP WITH TIME ZONE をサポートし、入力データ・タイプが java.sql.Timestamp であれば、ドライバーはターゲット・タイプとして TIMESTAMP WITH TIME ZONE を選択します。バージョン 3.63 または 4.13 以降において、ターゲット・データ・タイプが不明であり、ターゲット・データ・サーバーが TIMESTAMP WITH TIME ZONE をサポートし、入力データ・タイプが java.sql.Timestamp であれば、ドライバーはターゲット・タイプとして TIMESTAMP WITH TIME ZONE を選択します。ただし、入力オブジェクトの値が 0001-01-01-00:00:00.000000 または 9999-12-31-23:59:59.999999 の場合は除きます。 これらの場合、ドライバーはタイム・ゾーンなしの TIMESTAMP タイプを選択します。これらの 2 つの場合、TIMESTAMP データ・タイプが使用されることにより、暗黙のタイム・ゾーンの値の調整が原因で発生するオーバーフロー条件を防ぐことができます。 暗黙のタイム・ゾーンは、Java™ 仮想マシン (JVM) のタイム・ゾーンです。バージョン 3.65 または 4.15 以降において、ドライバーがタイム・ゾーンなしの TIMESTAMP タイプを選択する対象とするタイム・スタンプは、0001-01-01 (任意の時刻) または 9999-12-31 (任意の時刻) です。

getColumns の結果セットの列名の変更

バージョン 4.12 以前の IBM Data Server Driver for JDBC and SQLJ では、DatabaseMetaData.getColumns メソッドが SCOPE_CATLOG という名前の列を含む結果セットを返します。 バージョン 4.13 以降の IBM Data Server Driver for JDBC and SQLJ では、その列の名前は SCOPE_CATALOG です。 IBM Data Server Driver for JDBC and SQLJ が引き続き SCOPE_CATLOG という列名を使用するようにするには、DataSource または Connection のプロパティー useJDBC41DefinitionForGetColumns を DB2BaseDataSource.NO (2) に設定してください。

グローバル構成プロパティー db2.jcc.maxRefreshInterval、db2.jcc.maxTransportObjects、および db2.jcc.maxTransportObjectWaitTime のデフォルトの変更点

グローバル構成プロパティー db2.jcc.maxRefreshInterval、db2.jcc.maxTransportObjects、および db2.jcc.maxTransportObjectWaitTime のデフォルト値は、バージョン 3.63 および 4.13 の IBM Data Server Driver for JDBC and SQLJ で変更になります。 次の表は、新旧のデフォルトを示しています。

構成プロパティー バージョン 3.63 および 4.13 より前のデフォルト バージョン 3.63 および 4.13 以降のデフォルト
db2.jcc.maxRefreshInterval 30 秒 10 秒
db2.jcc.maxTransportObjects -1 (無制限) 1000
db2.jcc.maxTransportObjectWaitTime -1 (無制限) 1 秒

Connection および DataSource のプロパティー maxTransportObjects のデフォルト値に対する変更点

Connection および DataSource のプロパティー maxTransportObjects のデフォルト値は、IBM Data Server Driver for JDBC and SQLJ のバージョン 3.63 および 4.13 で変更されました。 次の表は、新旧のデフォルトを示しています。

Connection および DataSource プロパティー バージョン 3.63 および 4.13 より前のデフォルト値 バージョン 3.63 および 4.13 以降のデフォルト値
maxTransportObjects -1 (無制限) 1000

DB2 for z/OS のデータ共有グループへの接続に関する Connection および DataSource のプロパティー maxRetriesForClientReroute および retryIntervalForClientReroute のデフォルト値に対する変更点 (ドライバー・バージョン 3.64 および 4.14)

DB2 for z/OS データ共有グループへの接続について、Connection および DataSource のプロパティー maxRetriesForClientReroute および retryIntervalForClientReroute のデフォルト値は、IBM Data Server Driver for JDBC and SQLJ のバージョン 3.64 および 4.14 で変更されました。次の表に、新しいデフォルトをリストしています。

Connection および DataSource プロパティー バージョン 3.64 および 4.14 より前のデフォルト値 バージョン 3.64 および 4.14 以降のデフォルト値
maxRetriesForClientReroute 10 分間再試行され、初回再試行からの経過時間が長くなるにつれて、再試行と再試行の間の待ち時間は長くなります。 5
retryIntervalForClientReroute 10 分間再試行され、初回再試行からの経過時間が長くなるにつれて、再試行と再試行の間の待ち時間は長くなります。 0

DB2 for z/OS データ共有グループへの接続に関する Connection および DataSource のプロパティー maxRetriesForClientReroute のデフォルト値および再試行の意味に関する変更点 (ドライバー・バージョン 3.66 および 4.16)

DB2 for z/OS データ共有グループへの接続に関する Connection および DataSource のプロパティー maxRetriesForClientReroute のデフォルト値と再試行の意味は、IBM Data Server Driver for JDBC and SQLJ のバージョン 3.66 および 4.16 で変更されています。

以下の表に、以前のデフォルトと新しいデフォルトを示します。

プロパティーの変更 バージョン 3.66 および 4.16 より前 バージョン 3.66 および 4.16 以降
再試行の意味 データ共有グループの 1 つのメンバーへの 1 回の接続試行。 データ共有グループの失敗したメンバーを除くすべてのメンバーと、グループ IP アドレスへの 1 回の接続試行。この変更により、maxRetriesForClientReroute の値を低くすることが必要になる場合があります。
デフォルト値 DB2 for z/OS データ・サーバーへの接続の場合、以下のようになります。
  • データ共有グループへの初回接続で、maxRetriesForClientReroute も retryIntervalForClientReroute も設定されておらず、enableSysplexWLB プロパティーが true に設定されている場合、デフォルトでは、再試行間隔 0 で 5 回再試行することになります。
  • データ共有グループへの後続の接続中のフェイルオーバーにおいて、maxRetriesForClientReroute も retryIntervalForClientReroute も設定されておらず、enableSysplexWLB プロパティーが true に設定されていて、かつ、キャッシュに入れられたサーバー・リストまたは代替サーバーが指定されている場合、デフォルトでは、接続が 10 分間再試行され、初回再試行からの経過時間が長くなるにつれて再試行と再試行の間隔が長くなります。
enableSysplexWLB property が true に設定されている場合、デフォルトは 1 です。

DB2 for Linux, UNIX, and Windows DB2 pureScale インスタンス への接続再試行の意味に関する変更点 (ドライバー・バージョン 3.67 および 4.17)

DB2 for Linux, UNIX, and Windows DB2 pureScale® インスタンス への接続に対する自動クライアント・リルートの再試行の意味は、IBM Data Server Driver for JDBC and SQLJ のバージョン 3.67 および 4.17 で変更されています。

以下の表に、以前の意味と新しい意味を示します。

バージョン 3.67 および 4.17 より前の再試行の意味 バージョン 3.67 および 4.17 以降の再試行の意味
DB2 pureScale インスタンスの 1 つのメンバーへの 1 回の接続試行。 DB2 pureScale インスタンスのすべてのメンバーへの 1 回の接続試行。この変更により、maxRetriesForClientReroute の値を低くすることが必要になる場合があります。

DB2 for z/OS での IBM Data Server Driver for JDBC and SQLJ タイプ 2 接続 のクライアント情報プロパティーのデフォルト値の変更点

DB2 for z/OS での IBM Data Server Driver for JDBC and SQLJ タイプ 2 接続のクライアント情報プロパティーのデフォルト値は、バージョン 3.64 および 4.14 の IBM Data Server Driver for JDBC and SQLJ で変更になります。 次の表は、新旧のデフォルトを示しています。

クライアント情報プロパティー バージョン 3.64 および 4.14 より前のデフォルト値 バージョン 3.64 および 4.14 以降のデフォルト値
ApplicationName 空ストリング ストリング "db2jcc_application"
ClientAccountingInformation 空ストリング 空ストリング
ClientHostname 空ストリング ストリング "RRSAF"。
ClientUser 空ストリング 接続に指定されたユーザー ID。 ユーザー ID が指定されていない場合は、RACF® ユーザー ID が使用されます。

DB2 for z/OS のクライアント情報プロパティーの最大長に対する変更点

DB2 for z/OS 上での IBM Data Server Driver for JDBC and SQLJ タイプ 2 接続 のクライアント情報プロパティーの最大長が、IBM Data Server Driver for JDBC and SQLJ のバージョン 3.66 および 4.16 で変更されました。 以下の表に、以前の長さと新しい長さを示します。

クライアント情報プロパティー バージョン 3.68 および 4.18 より前の最大長 バージョン 3.68 および 4.18 以降の最大長
ApplicationName 32 255
ClientAccountingInformation 22 255
ClientHostname 18 255
ClientUser 16 128

グローバル構成プロパティー db2.jcc.enableInetAddressGetHostName のデフォルトに対する変更

IBM Data Server Driver for JDBC and SQLJ バージョン 3.65 および 4.15 以降、db2.jcc.enableInetAddressGetHostName のデフォルトは false になりました。 バージョン 3.64 および 4.14 以前のデフォルトは、true です。

xmlFormat プロパティーの動作の変更

IBM Data Server Driver for JDBC and SQLJ のバージョン 4.15 以降、Connection および DataSource の xmlFormat プロパティーは、XML データの更新と取り出しではなく、XML データの取り出しのみに適用されるようになりました。 加えて、デフォルトの動作が変更されました。データ・サーバーがバイナリー XML 形式をサポートするかどうかに関係なく、テキスト XML 形式での XML データの取り出しがデフォルトの動作になりました。

XML 列のデータの更新に関しては、xmlFormat は何の影響も与えません。 入力データがバイナリー XML データであり、データ・サーバーがバイナリー XML データをサポートしていない場合、入力データはテキスト XML データに変換されます。 それ以外の場合、変換は実行されません。

Connection および DataSource のプロパティー useCachedCursor のデフォルト値に対する変更

DB2 for Linux, UNIX, and Windows への接続の場合、Connection および DataSource の useCachedCursor プロパティーのデフォルト値が変更されています。

デフォルトは次のとおりです。

ドライバー・バージョンが 3.67 および 4.17 以降、または 3.64 および 4.14 以降であり、deferPrepares プロパティーが true に設定されている場合、useCachedCursor 設定に関係なく、ドライバーは useCachedCursor が false に設定されているかのように動作します。

自動クライアント・リルート時のシームレス・フェイルオーバーの失敗に対するドライバーの動作に関する変更

バージョン 3.67 および 4.17 より前の IBM Data Server Driver for JDBC and SQLJ でのシームレス・フェイルオーバー・エラー時の動作は、フェイルオーバー・サーバーへの再接続と以前に失敗した SQL ステートメントの実行を 10 回試行してから、ドライバーが SQL エラー・コード -20542 の SQLException を発行するというものでした。

IBM Data Server Driver for JDBC and SQLJ のバージョン 3.67 および 4.17 以降では、シームレス・フェイルオーバー・エラー時の動作として、フェイルオーバー・サーバーへの再接続と以前に失敗した SQL ステートメントの実行を 1 回試行した後に、ドライバーは SQL エラー・コード -4228 の SQLException を発行します。

トレース・ポーリングのデフォルトの変更

db2.jcc.tracePolling のデフォルトは、バージョン 3.69 より前の IBM Data Server Driver for JDBC and SQLJ では false ですが、バージョン 3.69 以降ではデフォルトは true です。