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:[EMAIL PROTECTED] > Sent: Tuesday, March 22, 2005 4:26 PM > To: [email protected] > 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/[EMAIL PROTECTED] > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
