org.hibernate.envers.test.integration.collection.StringMapNationalizedLobTest fails with DB2


DB2 FP1:
JDBC driver:

Version: 4.24.92
Bundle-Name: IBM JCC JDBC 4 Driver
Bundle-Version: 1.4.0




Chris Cranford
July 12, 2018, 1:31 PM

For DB2, I have a working solution where I am using what Steve suggests and overriding the SQLTypeDescriptor to use the non-nationalized equivalents instead. If we'd rather take that route, we certainly can or if we'd just rather remain status-quo and ignore the test for this dialect, I'm OK with that too. As for Sybase, I'll take a look at the dialect & link information and find a working solution before next week.

Steve Ebersole
July 19, 2018, 12:50 PM

I disagree with the conclusion about DB2... their documentation clearly says they support N* types assuming the database is created as a "unicode database" (whatever that means practically). Just because their driver does not is not the same thing.

I am curious if you could try defining the schema using NVARCHAR, e.g., but to treat it using the VARCHAR descriptor at runtime for binding (call #setString rather than #setNString), etc . I cannot remember if the sql type remapping happens for schema export as well...

WRT Sybase, the data type to use on the database (which is what the link you sent talks about) is just one part of the equation as hinted above here. The other part is which JDBC methods should be called. Assuming a column is this UNITEXT type do we read it using #getString? #getNString? #getClob? #getNClob? #getCharacterStream? ...?

Steve Ebersole
July 19, 2018, 1:39 PM

FWIW, jTDS at least treats Sybase UNITEXT type using Clob -

Chris Cranford
July 19, 2018, 1:42 PM

After talking with , we're going to split the Sybase problem into a separate issue since we have a fix for DB2. , the fix does exactly what you mention where the schema will be generated with the nclob/nvarchar types but we use the non-nationalized methods to operate with the driver to bypass the driver problem.

Moved the Sybase problem into HHH-12834.

Shaw, Polly
November 4, 2019, 10:25 AM

This might not be the right place to raise this, but the fix for the DB2 driver is only in DB297Dialect. I think it maybe should be in the DB2Dialect superclass instead, as that is the dialect that is automatically used when a DB2 connection is detected. Should I raise another bug?

(I'm raising this because I was experiencing the setNChar issue when connecting to DB2, and I looked at the commit on finding this thread.)


Chris Cranford


Martin Simka

Fix versions




Suitable for new contributors


Requires Release Note


Pull Request