aspose file tools*
The moose likes JDBC and the fly likes Windows vs. Linux behavior on ResultSet getString, top bit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Windows vs. Linux behavior on ResultSet getString, top bit" Watch "Windows vs. Linux behavior on ResultSet getString, top bit" New topic
Author

Windows vs. Linux behavior on ResultSet getString, top bit

Clayton Cramer
Ranch Hand

Joined: Aug 26, 2010
Posts: 41
I am running into an annoying problem. I have an application that under Windows retrieves strings from a database and the strings are what I would expect: 7-bit ASCII. Under Linux, the same application, talking to the same database, sometimes returns 8-bit ASCII. The particular symptom is that spaces, instead of being x'20', are x'a0' instead under Linux. My guess is that there is some method or setting for ResultSet or CallableStatement that says, "force all 8-bit character values to 7-bits" but I can't find it.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

Are you sure the database field is declared as a character (that is, not binary) type?

Java uses Unicode internally, so it's the JDBC driver's responsibility to handle character set conversions to match the database's character set. I'm not aware of any method that would allow you messing with that.

A quick search brought up some results that mentioned character set conversion bugs in JDBC drivers.
Clayton Cramer
Ranch Hand

Joined: Aug 26, 2010
Posts: 41
Martin Vajsar wrote:Are you sure the database field is declared as a character (that is, not binary) type?

Java uses Unicode internally, so it's the JDBC driver's responsibility to handle character set conversions to match the database's character set. I'm not aware of any method that would allow you messing with that.

A quick search brought up some results that mentioned character set conversion bugs in JDBC drivers.


Yes, it is declared as CHAR(30). It looks like DB_LOCALE and CLIENT_LOCALE are properties associated with the database connection, and this is likely the problem: under Windows, this is CP1252; under Linux, it defaults to UTF-8 or the ISO equivalent. I probably need to force the connection to CP1252, but I have not figured out how to do that yet.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

Do you use a thin driver? In that case, I'd suggest to check whether you're using the latest version (see our Oracle FAQ for links).

If you're using an OCI driver, perhaps the encoding might be changed using environment variables (LANG, I believe). I'm not sure whether it does affect the OCI driver when used via JDBC. I've only used this variable to change the locale for EXP and IMP in the past.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Windows vs. Linux behavior on ResultSet getString, top bit