Finished the migration from H2 to H3 with few/no problems....great work, by the way. As we're still in development mode, I decided to go ahead and use H3.1 since you'll probably go 'live' before we do.

Our system uses DB2/400 V5R3 in conjunction with v4.9 of the JTOpen JDBC drivers. Our 'naming' property is set to 'system' (lib/schema separator is '.').

Moving from RC2 to RC3 has broken the app with the more basic operations (inserting records, etc). It changes as I change the "hibernate.jdbc.use_get_generated_keys" config property.

The problem disappears moving from RC3 back to RC2 or 3.0.5.


When it's set to 'true', Hibernate is failing on insert with the following:

org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [com.EXCLUDED]; uncategorized SQLException for SQL [/* insert EXCLUDED.Quote */ insert into QUOTEMAST (version, QUOTENUM, ACCESEMAIL, PASSWORD, LASTACTION, LACTORD, QUOTETIME, INITTIME, COMPNUM, FIRSTNAME, MINITIAL, LASTNAME, ALTMAILING, MAILADR, MAILADRCTY, MAILADRST, MAILADRZIP, MADRVSTAT, ADDRESS, CITY, STATE, ZIP, GADRVSTAT, HOMEPHONE, WORKPHONE, EMAIL, EMPNAME, PRIORINS, PRINSCMP, PRPOLNUM, PRCOVSDATE, PRCOMPCOLL, PRCOVEDATE, OWNHOME, HOUSEMBRS, VEHICLELST, OTHERVEH, RATESTATE, EFFDATE, TERMEXPDT, AGENTNUM, YEARSADR, TERMLEN, PAYPLAN, TERCODE, TERCITY, POLTYPE, RESTRICT, DISTMETHOD, RATEBKCODE, PIPTYPE, BI, PD, UMBI, UMPD, UIMBI, UIMPD, MED, RENTAL, UMPDDED, TOW, MOTORCLUB, HOSINDEM, PDEXCL, PIPLIMIT, PIPDEDUCT, PIPWAGELOSS, PIPMILITARY, UMSTACK, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, default)]; SQL state [IM001]; error code [-99999]; The driver does not support this function.; nested exception is java.sql.SQLException: The driver does not support this function.
java.sql.SQLException: The driver does not support this function.


Changing the 'use_get_generated_keys' value to 'false' yields the following with the same operation:

org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [com.pgac.general.core.model.Quote]; uncategorized SQLException for SQL [select identity_val_local() from sysibm.sysdummy1]; SQL state [null]; error code [0]; Borrow prepareStatement from pool failed; nested exception is org.apache.commons.dbcp.SQLNestedException: Borrow prepareStatement from pool failed
org.apache.commons.dbcp.SQLNestedException: Borrow prepareStatement from pool failed
at org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:93)
at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:185)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:278)
[SNIPPED]
Caused by: java.sql.SQLException: [SQL5016] Qualified object name SYSDUMMY1 not valid. Cause . . . . . : One of the following has occurred: -- The syntax used for the qualified object name is not valid for the naming option specified. With system naming, the qualified form of an object name is schema-name/object-name. With SQL naming the qualified form of an object name is authorization-name.object-name. -- The syntax used for the qualified object name is not allowed. User-defined types cannot be qualified with the schema in the system naming convention on parameters and SQL variables of an SQL procedure or function. Recovery . . . : Do one of the following and try the request again: -- If you want to use the SQL naming convention, verify the SQL naming option in the appropriate SQL command and qualify the object names in the form authorization-id.object-name. -- If you want to use the system naming convention, specify the system naming option in the appropriate SQL command and qualify the object names in the form schema-name/object-name. -- With the system naming convention, ensure the user-defined types specified for parameters and variables in an SQL routine can be found in the current path.
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:650)
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:621)
at com.ibm.as400.access.AS400JDBCStatement.commonPrepare(AS400JDBCStatement.java:1481)
at com.ibm.as400.access.AS400JDBCPreparedStatement.<init>(AS400JDBCPreparedStatement.java:185)
at com.ibm.as400.access.AS400JDBCConnection.prepareStatement(AS400JDBCConnection.java:1880)
at com.ibm.as400.access.AS400JDBCConnection.prepareStatement(AS400JDBCConnection.java:1703)
at org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.java:188)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:747)
at org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:87)
... 79 more

Regarding the error regarding SYSDUMMY and the "hibernate.jdbc.use_get_generated_keys" setting, it does the same thing with RC2. It's not a problem with RC2 here, though, because it all works when this setting is left at default (true).

It is weird, however...the generated query:

identity_val_local() from sysibm.sysdummy1]
We use 'system' naming to properly set up the connection's library list on the as400. The error on that one reads:

Caused by: java.sql.SQLException: [SQL5016] Qualified object name SYSDUMMY1 not valid. Cause . . . . . : One of the following has occurred: -- The syntax used for the qualified object name is not valid for the naming option specified. With system naming, the qualified form of an object name is schema-name/object-name. With SQL naming the qualified form of an object name is authorization-name.object-name. -- The syntax used for the qualified object name is not allowed. User-defined types cannot be qualified with the schema in the system naming convention on parameters and SQL variables of an SQL procedure or function. Recovery . . . : Do one of the following and try the request again: -- If you want to use the SQL naming convention, verify the SQL naming option in the appropriate SQL command and qualify the object names in the form authorization-id.object-name. -- If you want to use the system naming convention, specify the system naming option in the appropriate SQL command and qualify the object names in the form schema-name/object-name. -- With the system naming convention, ensure the user-defined types specified for parameters and variables in an SQL routine can be found in the current path.

So, it seems perhaps the DB2400Dialect handler should perhaps 'sense' which 'naming' setting is being used. That still doesn't explain why moving to RC3 from RC2 "broke" all operations (at least here for me with this DB2/400 app).