[unixODBC-support] Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Nick Gorham nick at lurcher.org
Tue Sep 20 12:03:34 BST 2016


On 20/09/16 10:42, Edouard Gaulué wrote:
> Nice to have come back on it to explain it more.
>
> On the web you can find this: 
> https://msdn.microsoft.com/en-us/library/hh568448(v=sql.110).aspx that 
> may be clearer for you than for me. The Driver Manager recommanded and 
> installed by Microsoft on Linux is unixODBC.
>
> I have enabled logging, and it's driving me mad. I've got two version 
> of unixODBC, one with --with-iconv-char-enc=UTF-8 (version1) and the 
> other not (version2).
>
> Here are the results comparing logs and what I see in my bash which is 
> utf8 locale (hex code for 'è' is tabulated on the right):

Ok, just checked, the MS driver seems to only have the W(ide) entry 
points, so the driver manager is having to do the conversion from the 
narrow to wide, so it must be built with the UTF-8 set to use iconv to 
convert.

On the way back it will depend on what the application asks the driver 
for the data as. isql will ask for a SQL_CHAR (its a simple test app), 
so the driver manager will not do any conversion as its got none to do. 
The Easysoft driver (I can speak about this as I work for Easysoft) has 
both the Wide and 8 bit API calls, so the driver can be in charge of its 
own conversions to and from wide to UTF8.

There is not a great deal unixODBC can do here, it was assumed that most 
drivers wound have both single and multiple byte API's. If the app is 8 
bit and the driver only W, then any SQL will go via iconv to convert, so 
that should do as expected, getting data back is down to the app and the 
driver knowing what they expect. If the app calls for a WCHAR type, and 
the driver is a ODBC2 driver (no unicode) then the driver manager will 
do the conversion. But in the case of a ODBC3 driver like the MS one, 
its assumed that the driver can handle both 8 and 16 bit characters.

What sqlcmd is doing is taking the c3a8 UTF representation of è and 
converting it into e8 which is what sqlserver is expecting, and on the 
way back getting e8 and converting that back to c3a8 as UTF8

To be honest, I have just tried it with isql and the MS driver and 
unixODBC with UTF8 iconv and it all seems to work as I would expect in isql

-- 
Nick


More information about the unixODBC-support mailing list