DB2 184.108.40.206 FP1:
Bundle-Name: IBM JCC JDBC 4 Driver
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.
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? ...?
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.
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 https://github.com/hibernate/hibernate-orm/commit/005d5b7c748c4c03afddae43a6fc2299869ab0f9#diff-b1052d2e415405ea6c0e4cd1a0403077 on finding this thread.)