JDBC アプリケーションを古いドライバーから IBM® Data Server Driver for JDBC and SQLJ の新しいバージョンにアップグレードする前に、それらのドライバー間の相違点を理解する必要があります。
IBM Data Server Driver for JDBC and SQLJ がサポートするメソッドのリストについては、JDBC API でのドライバーのサポートに関する情報を参照してください。
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 の以前のバージョンは、連続ストリーミングをサポートしません。
…
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 内の値は使用できなくなります。この動作の変更によるエラーを避けるには、以下のアクションのいずれかをとる必要があります。
LOB データをアプリケーション変数に取り出すアプリケーションは、データの取り出しに使用されたカーソルが移動されるか閉じられるまでの間に限り、それらのアプリケーション変数のデータを操作できます。
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 オブジェクトは自動生成キーを戻しません。
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 ステートメントによって影響を受ける行数が含まれます。
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 以降、この制限はもはや存在せず、例外はスローされなくなりました。
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 ドライバー、バージョン、または接続のいずれかがそれとは異なる場合、初期値は設定されていません。
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 がスローされます。
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) 列に渡す場合、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) 列にあればデータ損失は生じません。
バージョン 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 (任意の時刻) です。
バージョン 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 のデフォルト値は、バージョン 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 のデフォルト値は、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 のデフォルト値は、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 のデフォルト値と再試行の意味は、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 データ・サーバーへの接続の場合、以下のようになります。
|
enableSysplexWLB property が true に設定されている場合、デフォルトは 1 です。 |
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 接続のクライアント情報プロパティーのデフォルト値は、バージョン 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 上での 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 |
IBM Data Server Driver for JDBC and SQLJ バージョン 3.65 および 4.15 以降、db2.jcc.enableInetAddressGetHostName のデフォルトは false になりました。 バージョン 3.64 および 4.14 以前のデフォルトは、true です。
IBM Data Server Driver for JDBC and SQLJ のバージョン 4.15 以降、Connection および DataSource の xmlFormat プロパティーは、XML データの更新と取り出しではなく、XML データの取り出しのみに適用されるようになりました。 加えて、デフォルトの動作が変更されました。データ・サーバーがバイナリー XML 形式をサポートするかどうかに関係なく、テキスト XML 形式での XML データの取り出しがデフォルトの動作になりました。
XML 列のデータの更新に関しては、xmlFormat は何の影響も与えません。 入力データがバイナリー XML データであり、データ・サーバーがバイナリー XML データをサポートしていない場合、入力データはテキスト XML データに変換されます。 それ以外の場合、変換は実行されません。
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 です。