Re: JDBC driver is too fussy about Unicode

James Pharaoh wrote:
 > The test case works for me, and also on the server. A little
 > investigation shows one big difference, the code I am using is somehow
 > using a JDBC2 statement class, whereas adding some output to the test
 > case when it runs successfully shows me using a JDBC4 one.
 >
 > Furthermore, the app in question has a page where I can enter queries
 > in groovy. Trying a similar testcase there also works, but I am
 > getting a JDBC3 statement class.
 >
 > I have a feeling this might be a big part of the problem but don't
 > really know enough about what is going on underneath to be sure. I am
 > using Hibernate 3.3.2 which is a little old.
 >
 > I wonder if it is somehow managing to force the driver to use JDBC2?
 > How would you write a testcase to do this?
 >
 > Does the JDBC driver for PostgreSQL contain compatibility code for
 > JDBC2 and could it be that there is a bug there?
 >
 > Of course, I could try and upgrade Hibernate as well. I'll look into
 > that but the last time I had to do that it didn't work out so well.
 >
 > Thanks,
 > James
 >
 > 2011/10/29 Oliver Jowett<oliver@opencloud.com>:
 >> On 29 October 2011 13:17, Oliver Jowett<oliver@opencloud.com>  wrote:
 >>
 >>> Can't reproduce it here; the attached testcase works fine for me
 >>
 >> Oops, testcase really attached this time.
 >>
 >> Oliver

Oliver's test case on my setup fails in the insert because the database
indicates the character 0xf09f9480 of encoding "UTF8" has no equivalent
in "LATIN1".

The original error given is thrown in the class indicated but the only
thing really going on there is a new String creation with the encoding
derived from the connection. What I would like to see is what that
encoding is for Oliver's sucessful test case and then again on the app
if possible. Not sure right now how to do that, but I would say that
encoding is not being returned the same through the app. with hibernate
as when the JDBC is ran directly.

The only other thing maybe is the encodedString returned. See below:

danap

Abstractjdbc2ResultSet.getString()
{
~
~
Encoding encoding = connection.getEncoding();
         try
         {
             return trimString(columnIndex, encoding.decode(this_row[columnIndex
- 1]));
         }
         catch (IOException ioe)
         {
             throw new PSQLException(GT.tr("Invalid character data was found.
This is most likely caused by stored data containing characters that are invalid
for the character set the database was created in.  The most common example of
this is storing 8bit data in a SQL_ASCII database."), PSQLState.DATA_ERROR, ioe);
         }

 From Encoding:

public String decode(byte[] encodedString) throws IOException
     {
         return decode(encodedString, 0, encodedString.length);
     }

public String decode(byte[] encodedString, int offset, int length) throws
IOException
     {
         if (encoding == null)
             return new String(encodedString, offset, length);

-------->        return new String(encodedString, offset, length, encoding);
     }