[unixODBC-support] DSN=... notation not accepted
nick.gorham at easysoft.com
Fri Oct 31 15:25:34 GMT 2008
Andreas Buschka wrote:
>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 :-)
More information about the unixODBC-support