suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IT40596 Status: Closed

Driver throws ARRAYINDEXOUTOFBOUNDEXCEPTION in SQLJ heterogeneous batch
environment

product:
DB2 CONNECT / DB2CONNCT / B50 - DB2
Problem description:
In SQLJ Program that uses batch execution of the statements, if
each prepared statement in the batch is same then
this issue do not happen. If in the batch, each prepared
statement is different in terms of number of positional
parameter, then
you may hit ARRAYINDEXOUTOFBOUNDEXCEPTION  from SQLJ.
 .
e.g:
#sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,
KEY)VALUES (:inr,'DB2_SQLJ_INSERT_TEST1',:BOUND_USERID,:key1)

#sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,
KEY)VALUES (:inr,'DB2_SQLJ_INSERT_TEST1','NOT BOUND',:key1)


As in above first insert prepared statement binds 3 variable but
second binds only two. When second statement is executed in
batch context , JCC
driver uses previous prepared statement and since the second
statement differs in the actual number of positional parameters,
ARRAYINDEXOUTOFBOUNDEXCEPTION  is hit.

You may observe following stack when you hit this error for
above example:
java.lang.ArrayIndexOutOfBoundsException: Array index out of
range: 2

     at
com.ibm.db2.jcc.t4.ah.computeDrdaTypesAndLengthsForColumn(ah.jav
a:2284) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.t4.ah.a(ah.java:2251) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.t4.ah.a(ah.java:2209) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.t4.ah.a(ah.java:955) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.t4.ah.a(ah.java:284) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.t4.aw.a(aw.java:190) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.a(k_.java:3606) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.a(k_.java:5791) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.a(k_.java:5715) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.a(k_.java:5399) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.c(k_.java:5059) ~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.am.k_.executeBatch(k_.java:5025)
~[db2jcc4.jar:?]
     at com.ibm.db2.jcc.sqlj.a.executeBatch(a.java:38)
~[db2jcc4.jar:?]
     at
sqlj.runtime.ExecutionContext.executeBatch(ExecutionContext.java
:356) ~[db2jcc4.jar:?]
Problem Summary:
****************************************************************
* USERS AFFECTED:                                              *
* IBM DB2 JDBC Driver Level 4.29.24 (V11.5 M6 FP0 JDBC & SQLJ) *
* Users                                                        *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* SSQLJ Programs generally to batch execution of prepared      *
* statements. In the batch if each prepared statement is same  *
* then this issue not happens. If in the batch, each prepared  *
* statement is different in terms of number of positional      *
* parameter then only this issue happens.                      *
*                                                              *
* #sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,      *
* KEY)VALUES                                                   *
* (:inr,'DB2_SQLJ_INSERT_TEST1',:BOUND_USERID,:key1)           *
* #sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,      *
* KEY)VALUES (:inr,'DB2_SQLJ_INSERT_TEST1','NOT BOUND',:key1)  *
*                                                              *
* As in above first insert prepared statement binds 3 variable *
* but second binds only two. When this executed in batch       *
* context , JCC driver was internally using previous prepared  *
* statement.ee Error Description                               *
****************************************************************
* RECOMMENDATION:                                              *
* Fix available in JCC 4.32 (V11.5 M8 FP0 JDBC & SQLJ)         *
****************************************************************
Local Fix:
NA
Solution
Workaround
****************************************************************
* USERS AFFECTED:                                              *
* IBM DB2 JDBC Driver Level 4.29.24 (V11.5 M6 FP0 JDBC & SQLJ) *
* Users                                                        *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* SSQLJ Programs generally to batch execution of prepared      *
* statements. In the batch if each prepared statement is same  *
* then this issue not happens. If in the batch, each prepared  *
* statement is different in terms of number of positional      *
* parameter then only this issue happens.                      *
*                                                              *
* #sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,      *
* KEY)VALUES                                                   *
* (:inr,'DB2_SQLJ_INSERT_TEST1',:BOUND_USERID,:key1)           *
* #sql [ctx] {INSERT INTO TEMP_TABLE ( INR,P_NAME,USERID,      *
* KEY)VALUES (:inr,'DB2_SQLJ_INSERT_TEST1','NOT BOUND',:key1)  *
*                                                              *
* As in above first insert prepared statement binds 3 variable *
* but second binds only two. When this executed in batch       *
* context , JCC driver was internally using previous prepared  *
* statement.ee Error Description                               *
****************************************************************
* RECOMMENDATION:                                              *
* Fix available in JCC 4.32 (V11.5 M8 FP0 JDBC & SQLJ)         *
****************************************************************
Comment
Fixed in JCC 4.32 (V11.5 M8 FP0 JDBC & SQLJ)
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
11.04.2022
07.10.2022
24.10.2022
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)