RE: Issue when updating or inserting non-ASCII characters to VARCHAR UNICODE column

Hello Johan,

I'm quite sure that the JDBC driver is not the primary issue,
as you use prepared statements. 

To verify what's really going on, please make a JDBC trace
(this will show what's supplied to the JDBC calls by your
 application), and a vtrace to see what the database is
actually getting from the interface.

Look under http://sapdb.2scale.net/moin.cgi/TroubleShooting 
for a quick overview on how to produce these traces. 

Also, can you tell the version of the JDBC driver used, and 
can you repeat the test with the most recent one, if you use
an older version?

Regards
Alexander Schröder
SAP DB, SAP Labs Berlin

> -----Original Message-----
> From: Hellgren, Johan [mailto:Johan.Hellgren@xxxxxxxxxxxxxxx] 
> Sent: Tuesday, March 22, 2005 4:26 PM
> To: maxdb@xxxxxxxxxxxxxxx
> Subject: Issue when updating or inserting non-ASCII 
> characters to VARCHAR UNICODE column
> 
> Hello list,
> 
> I am in the process of enabling a content management system 
> of ours for international use. Its architecture is an SAPDB 
> 7.4.3.27 database instance as the back end, and Resin 2.1.16 
> as the application server, using the SAPDB JDBC driver to 
> communicate with the database. The database instance is set 
> to _UNICODE=YES.
> 
> The issue that I'm experiencing is that when inserting or 
> updating a field using a PreparedStatement of Sun's JDK 
> 1.4.2, odd character conversions occur if the target field is 
> of type VARCHAR(100) UNICODE, but works better if the field 
> is of type LONG UNICODE. A specific example for the ç 
> (ç) character is:
> 
> Let TBLLANGUAGENAME have two columns: ID UNIQUE INTEGER, 
> LANGUAGENAME VARCHAR(100) UNICODE
> 
> Using a prepared statement to execute "UPDATE TBLLANGUAGENAME 
> SET LANGUAGENAME=? WHERE IID=?", where ID is an existing 
> unique id, and LANGUAGENAME='Français', fails with the ç 
> being translated to ç. However, the same statement using SQL 
> Studio works, the ç gets into the LANGUAGENAME field.
> 
> If instead the table is defined like this:
> 
> Let TBLLANGUAGENAME have two columns: ID INTEGER, 
> LANGUAGENAME LONG UNICODE,
> 
> using the same prepared statement with same parameters as 
> above works to an extent. Instead of updating a ç into the 
> LONG field, Français gets translated to Français, 
> which of course also works for html display purposes.
> 
> What do I need to do to avoid getting non-ASCII character 
> mistranslations in VARCHAR fields? Is it even possible, or 
> (more likely), am I missing something fundamental?
> 
> Thanks for your insight!
> /Johan Hellgren
> 
> -- 
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe:    
> http://lists.mysql.com/maxdb?unsub=alexander.schroeder@xxxxxxx
> 
> 

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx