[unixODBC-support] Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)
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
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
More information about the unixODBC-support