[unixODBC-support] DSN=... notation not accepted

Nick Gorham nick.gorham at easysoft.com
Fri Oct 31 15:25:34 GMT 2008

Andreas Buschka wrote:

>Hello Nick,
>I also tried changing a character to a high Unicode value like "ê" and could show (by looking at the len counter) that Oracle indeed sends UTF-8, not ANSI. Having reviewed how other ODBC stacks like iODBC or Win32 handle this (they also expect UTF-16), I have come to the conclusion that Oracle is wrong on this one, so I opened a service request there and will see if I can convince them.
>Is there any way to work around that problem, e.g. making unixODBC accept UTF8 strings from client applications? I looked at the source code, but my C knowledge is too limited to do it on my own :-/
>Another idea: Can I compile unixODBC without any Unicode support at all? Maybe this could force Oracle to send only ANSI, thereby creating a workaround for the time being.
>unixODBC-support mailing list
>unixODBC-support at mailman.unixodbc.org

The only way we have found to get around it at Easysoft is to not use 
the driver manager, and have a flag in the drivers that expects utf-8.

Its all a bit silly (IMHO), the X-Open spec is clear that multi byte 
sequences can be handled in ODBC 3, by the use of the desc octet length 
and char length fields, there are still slight problems with SQLGetData, 
but in reality there is no reason to need the W functions to deal with 
UTF-8. The X-Open spec doesn't cover the W functions at all, and the 
implication is that UTF-8 should be sent via the normal 8bit character 
functions. It says as such about character set issues.

The W functions (Where W means wide, not unicode remember but 16bit wide 
encoding as it originally was on windows) is a MS addition, and I thing 
its just a silly move using the API in the way Oracle does. I can 
understand the use of 4 byte characters as iODBC does, I don't think its 
right, but I understand the reason for them doing that.

The only way I could see around your problem is to see if Oracle 
defaults to calling the non W functions if they are not exported from 
libodbc.so, and if it does, then taking the W functions out of 
DriverManager/Makefile.in and creating a ANSI only version of the drive 

If that doesn't work, you would need to remove all the code for the W 
functions and replace with the non W versions.

But there is more for you to find, it also expects the data that comes 
back from a SQLGetData( SQL_W_CHAR ) to be 8 bit as well, so the driver 
needs to get involved, or you need to map in the driver manager.

Its all a mess. To be truthfull, the solution is the people behind the 
Oracle db4odbc code to get a clue, but I am not holding my breath.

By the way, I am not incuding the folk who work on the Oracle ODBC 
driver in this, they seem to have the same view on unicode as the rest 
of us, so its clearly not a company wide lack of clue :-)

Nick Gorham

More information about the unixODBC-support mailing list