The problem is that I cannot fetch data for a select because (maybe) of an encoding issue.
My select looks like:
"select id from mytable where data=?"
I bind the parameter from my ODBC application and I'm sure the bound value is correct and matches the value stored in the database.
The data column is VARGRAPHIC and the db encoding parameters are the default.
When I go fetching data for this select, it doesn't fetch anything, because for some reason the data parameter that is passed, which is UFT-8, doesn't exactly match the value in the db.
The same code on Windows works fine.
What could I do to solve this issue?
Thanks a lot for any help
try to display the data as it is in the db
connect locally or from db2 client and select hex(col) from table
try to active cli/odbc trace and what you ship as request
Best Regards, Guy Przytula
Database Software Consultant
Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
Information Server Datastage Certified http://www.infocura.be
I made some progress, the cause is the fact that from my odbc application I'm binding the parameter using an UTF-16 string, and then it doesn't fetch anything because my database is UTF-8 and the 2 strings don't match.
This because I'm porting the application from SQL Server (Windows based) and it used do deal with wide chars.
Now on Linux I don't want to rewrite all my application, so I'm looking for a smart way to solve this issue.
Can someone suggest a way to handle this at database server side without having to change all my application?
I'm looking for a way to tell the db: the data I'm binding is UTF-16, please do the conversion to UFT-8 before using the data.
On Linux the client codepage is derived from the OS current locale setting. You can either change that, or try setting the environment variable DB2CODEPAGE=1200; not sure if the latter will override the default behaviour though.