Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Edouard Gaulué
Dear community,

I'm not sure I've a trouble to fix but I just would like to know if my
understanding is correct.

I try to use the Microsoft SQL Server Driver for Linux with unixodbc. I
use the Debian Jessie distribution with the stable unixodbc package, so
version 2.3.1.

My locale is set to en_US.UTF-8.


*** USING sqlcmd ***

Using the sqlcmd tool provided by Microsoft with the driver, I manage to
read and write characters outside of ASCII:

1> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
2> GO
(1 rows affected)

1> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
2> GO
EU_ENUMERE
-------------------------
La pièce
(1 rows affected)


*** USING isql ***

When I use isql, I manage to read characters outside of ASCII, but not
to write them:

SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
+--------------------------+
| EU_ENUMERE               |
+--------------------------+
| La pièce                |
+--------------------------+
SQLRowCount returns 0
1 rows fetched

SQL> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
SQLRowCount returns 1

SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
+--------------------------+
| EU_ENUMERE               |
+--------------------------+
| La pièce              |
+--------------------------+
SQLRowCount returns 0
1 rows fetched


*** Looking at the traces ***

All my traces show:
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'.

I haven't found any way to make this to switch to UTF-8 from the command
line or through odbc.ini or odbcinst.ini. Is there ?


*** Compiling unixodbc to use UTF-8 ***

I've changed the debian/rules and add --with-iconv-char-enc=UTF-8,
compiled and installed resulting unixodbc and libodbc package.

Now, I observe in the traces:
UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2LE'

And both handle accented chars.


*** Analyse ***

sqlcmd maybe integrates something to detect your encoding and to comply
with the connexion one. isql doesn't, nor PHP through PDO. But, if
default is set to UTF-8 then those applications do the job.


*** Questions ***

How can read (SELECT) be OK and not write (INSERT, UPDATE) ? That the
first thing I found strange. Why applications understand the output
should be in UTF-8 whereas thay are said to be in ISO8859-1. Is it a
kind of OS feature, knowing you are displaying UTF-8 ?

As far as I understand, --with-iconv-char-enc=UTF-8 changes the default
character encoding but it can be overrided by directives/options, if
implemented. Is this true?

If not, what is the risk of compiling with --with-iconv-char-enc=UTF-8 ?
on a UTF-8 OS ?



_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Nick Gorham-2
On 15/09/16 16:52, Edouard Gaulué wrote:

> Dear community,
>
> I'm not sure I've a trouble to fix but I just would like to know if my
> understanding is correct.
>
> I try to use the Microsoft SQL Server Driver for Linux with unixodbc.
> I use the Debian Jessie distribution with the stable unixodbc package,
> so version 2.3.1.
>
> My locale is set to en_US.UTF-8.
>
>
> *** USING sqlcmd ***
>
> Using the sqlcmd tool provided by Microsoft with the driver, I manage
> to read and write characters outside of ASCII:
>
> 1> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
> 2> GO
> (1 rows affected)
>
> 1> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> 2> GO
> EU_ENUMERE
> -------------------------
> La pièce
> (1 rows affected)
>
>
> *** USING isql ***
>
> When I use isql, I manage to read characters outside of ASCII, but not
> to write them:
>
> SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> +--------------------------+
> | EU_ENUMERE               |
> +--------------------------+
> | La pièce                |
> +--------------------------+
> SQLRowCount returns 0
> 1 rows fetched
>
> SQL> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
> SQLRowCount returns 1
>
> SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> +--------------------------+
> | EU_ENUMERE               |
> +--------------------------+
> | La pièce              |
> +--------------------------+
> SQLRowCount returns 0
> 1 rows fetched
>
>
> *** Looking at the traces ***
>
> All my traces show:
> UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'.
>
> I haven't found any way to make this to switch to UTF-8 from the
> command line or through odbc.ini or odbcinst.ini. Is there ?
>
>
> *** Compiling unixodbc to use UTF-8 ***
>
> I've changed the debian/rules and add --with-iconv-char-enc=UTF-8,
> compiled and installed resulting unixodbc and libodbc package.
>
> Now, I observe in the traces:
> UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2LE'
>
> And both handle accented chars.
>
>
> *** Analyse ***
>
> sqlcmd maybe integrates something to detect your encoding and to
> comply with the connexion one. isql doesn't, nor PHP through PDO. But,
> if default is set to UTF-8 then those applications do the job.
>
>
> *** Questions ***
>
> How can read (SELECT) be OK and not write (INSERT, UPDATE) ? That the
> first thing I found strange. Why applications understand the output
> should be in UTF-8 whereas thay are said to be in ISO8859-1. Is it a
> kind of OS feature, knowing you are displaying UTF-8 ?
>
> As far as I understand, --with-iconv-char-enc=UTF-8 changes the
> default character encoding but it can be overrided by
> directives/options, if implemented. Is this true?
>
> If not, what is the risk of compiling with --with-iconv-char-enc=UTF-8
> ? on a UTF-8 OS ?

Generally unixODBC will pass through what its given. The only time that
iconv setting is involved is if the driver needs to convert from W to A,
or A to W. As long as the driver has both A and W entry points the
driver manager is not involved.

isql is just a simple test app, it will read from standard input based
on the existing LANG, so as long as you have a UTF8 LANG, and are
passing UTF8 into it, the druver will recieve UTF8 and then its up to it
what it does with the data.

--
Nick
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Michael König
Hi Edouard!

Unfortunately, I am not familiar with the MSQL database and its driver. I know, however, that some ODBC drivers depend on the currently set locale (environment variables LCALL and LOCALE are often used). If the locale does not support UTF-8 (default C locale, for example), strange effects may happen with these databases. Sometimes, the drivers also offer options to set the locale for the database session only.

Perhaps this gives you a new angle to tackle your problem.

Cheers

Michael


On 15/09/16 19:28, "[hidden email] on behalf of Nick Gorham" <[hidden email] on behalf of [hidden email]> wrote:

    On 15/09/16 16:52, Edouard Gaulué wrote:
    > Dear community,
    >
    > I'm not sure I've a trouble to fix but I just would like to know if my
    > understanding is correct.
    >
    > I try to use the Microsoft SQL Server Driver for Linux with unixodbc.
    > I use the Debian Jessie distribution with the stable unixodbc package,
    > so version 2.3.1.
    >
    > My locale is set to en_US.UTF-8.
    >
    >
    > *** USING sqlcmd ***
    >
    > Using the sqlcmd tool provided by Microsoft with the driver, I manage
    > to read and write characters outside of ASCII:
    >
    > 1> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
    > 2> GO
    > (1 rows affected)
    >
    > 1> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
    > 2> GO
    > EU_ENUMERE
    > -------------------------
    > La pièce
    > (1 rows affected)
    >
    >
    > *** USING isql ***
    >
    > When I use isql, I manage to read characters outside of ASCII, but not
    > to write them:
    >
    > SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
    > +--------------------------+
    > | EU_ENUMERE               |
    > +--------------------------+
    > | La pièce                |
    > +--------------------------+
    > SQLRowCount returns 0
    > 1 rows fetched
    >
    > SQL> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
    > SQLRowCount returns 1
    >
    > SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
    > +--------------------------+
    > | EU_ENUMERE               |
    > +--------------------------+
    > | La pièce              |
    > +--------------------------+
    > SQLRowCount returns 0
    > 1 rows fetched
    >
    >
    > *** Looking at the traces ***
    >
    > All my traces show:
    > UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'.
    >
    > I haven't found any way to make this to switch to UTF-8 from the
    > command line or through odbc.ini or odbcinst.ini. Is there ?
    >
    >
    > *** Compiling unixodbc to use UTF-8 ***
    >
    > I've changed the debian/rules and add --with-iconv-char-enc=UTF-8,
    > compiled and installed resulting unixodbc and libodbc package.
    >
    > Now, I observe in the traces:
    > UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2LE'
    >
    > And both handle accented chars.
    >
    >
    > *** Analyse ***
    >
    > sqlcmd maybe integrates something to detect your encoding and to
    > comply with the connexion one. isql doesn't, nor PHP through PDO. But,
    > if default is set to UTF-8 then those applications do the job.
    >
    >
    > *** Questions ***
    >
    > How can read (SELECT) be OK and not write (INSERT, UPDATE) ? That the
    > first thing I found strange. Why applications understand the output
    > should be in UTF-8 whereas thay are said to be in ISO8859-1. Is it a
    > kind of OS feature, knowing you are displaying UTF-8 ?
    >
    > As far as I understand, --with-iconv-char-enc=UTF-8 changes the
    > default character encoding but it can be overrided by
    > directives/options, if implemented. Is this true?
    >
    > If not, what is the risk of compiling with --with-iconv-char-enc=UTF-8
    > ? on a UTF-8 OS ?
   
    Generally unixODBC will pass through what its given. The only time that
    iconv setting is involved is if the driver needs to convert from W to A,
    or A to W. As long as the driver has both A and W entry points the
    driver manager is not involved.
   
    isql is just a simple test app, it will read from standard input based
    on the existing LANG, so as long as you have a UTF8 LANG, and are
    passing UTF8 into it, the druver will recieve UTF8 and then its up to it
    what it does with the data.
   
    --
    Nick
    _______________________________________________
    unixODBC-support mailing list
    [hidden email]
    http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
   


_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Nick Gorham-2
In reply to this post by Edouard Gaulué
On 15/09/16 16:52, Edouard Gaulué wrote:

> Dear community,
>
> I'm not sure I've a trouble to fix but I just would like to know if my
> understanding is correct.
>
> I try to use the Microsoft SQL Server Driver for Linux with unixodbc.
> I use the Debian Jessie distribution with the stable unixodbc package,
> so version 2.3.1.
>
> My locale is set to en_US.UTF-8.
>
>
> *** USING sqlcmd ***
>
> Using the sqlcmd tool provided by Microsoft with the driver, I manage
> to read and write characters outside of ASCII:
>
> 1> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
> 2> GO
> (1 rows affected)
>
> 1> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> 2> GO
> EU_ENUMERE
> -------------------------
> La pièce
> (1 rows affected)
>
>
> *** USING isql ***
>
> When I use isql, I manage to read characters outside of ASCII, but not
> to write them:
>
> SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> +--------------------------+
> | EU_ENUMERE               |
> +--------------------------+
> | La pièce                |
> +--------------------------+
> SQLRowCount returns 0
> 1 rows fetched
>
> SQL> UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE id=1105270
> SQLRowCount returns 1
>
> SQL> SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
> +--------------------------+
> | EU_ENUMERE               |
> +--------------------------+
> | La pièce              |
> +--------------------------+
> SQLRowCount returns 0
> 1 rows fetched
>
>
> *** Looking at the traces ***
>
> All my traces show:
> UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'.
>
> I haven't found any way to make this to switch to UTF-8 from the
> command line or through odbc.ini or odbcinst.ini. Is there ?
>
>
> *** Compiling unixodbc to use UTF-8 ***
>
> I've changed the debian/rules and add --with-iconv-char-enc=UTF-8,
> compiled and installed resulting unixodbc and libodbc package.
>
> Now, I observe in the traces:
> UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2LE'
>
> And both handle accented chars.
>
>
> *** Analyse ***
>
> sqlcmd maybe integrates something to detect your encoding and to
> comply with the connexion one. isql doesn't, nor PHP through PDO. But,
> if default is set to UTF-8 then those applications do the job.

i think its possible that sqlcmd is reading the input and converting in
itself into wide characters, and then calling the W functions the driver
so UTF8 is not being seen by the driver. And likewise with data coming
back. isql is a simple test tool that is not specific to any driver so
just takes a string from the terminal and passes it to the ansi api calls.
>
>
> *** Questions ***
>
> How can read (SELECT) be OK and not write (INSERT, UPDATE) ? That the
> first thing I found strange. Why applications understand the output
> should be in UTF-8 whereas thay are said to be in ISO8859-1. Is it a
> kind of OS feature, knowing you are displaying UTF-8 ?

Not sure, I would turn on unixODBC logging and see what the app is doing
with the driver.
>
> As far as I understand, --with-iconv-char-enc=UTF-8 changes the
> default character encoding but it can be overrided by
> directives/options, if implemented. Is this true?
>
> If not, what is the risk of compiling with --with-iconv-char-enc=UTF-8
> ? on a UTF-8 OS ?

Normally none. The only time the driver manager will use that info is
when it needs to convert from wide to ansi and vice versa. So for
example if the driver only has the W functions, and the application
calls the A points, the the driver manager will call teh W function on
the applications behalf converting the data using the selected encoding.

I am not sure about the MS driver, but the Easysoft SQL Server driver
has the ability to set the client side encoding, so the driver knows 1.
Client character set, 2. Server character set (from the server info), so
can convert correctly from 1 to 2, and back.

--
Nick
>
>
>
>
> _______________________________________________
> unixODBC-support mailing list
> [hidden email]
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support


_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Edouard Gaulué
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):

UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2LE'
     sqlcmd
         execute UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE
id=1105270
             bash-utf8: UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270                c3a8
             log: SQL = [UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La
pi?ce' WHERE id=1105270                e8
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             log: Buffer = [La pi?ce](unicode)                        
                 e8
             bash-utf8: La pièce                                        
c3a8
     sqli
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             log: Buffer = [La pièce]                                
         c3a8
             bash-utf8: La pièce                                        
c3a8
         execute UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE
id=1105270
             bash-utf8: UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270                c3a8
             SQL = [UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270][length = 66]        c3a8
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             Buffer = [La pièce]                                        
c3a8
             bash-utf8: La pièce                                        
c3a8

UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
     sqlcmd
         execute UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE
id=1105270
             bash-utf8: UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270                c3a8
             SQL = [UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270                      c3a8
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             Buffer = [La pièce](unicode)                            
             c3a8
             bash-utf8: La pièce                                        
c3a8
     sqli
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             Buffer = [La pièce]                                    
     c383 c2a8    <--- why ?
             bash-utf8: La pièce                                        
c3a8         <-----|
         execute UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce' WHERE
id=1105270
             bash-utf8: UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270                c3a8
             SQL = [UPDATE EXP_F_DOCLIGNES SET EU_ENUMERE='La pièce'
WHERE id=1105270][length = 66]        c383 c2a8
         request SELECT EU_ENUMERE FROM EXP_F_DOCLIGNES WHERE id=1105270
             Buffer = [La pièce]                                    
        c383 c283 c382 c2a8
             bash-utf8: La pièce                                    
     c383 c2a8


Does anybody know:
  * if logging is done before or after charset conversion? For execute?
For request results?
  * if logging is done on converted request/execute even if conversion
is not involved?

It looks like sqlcmd use a lot of W functions and SQL result is said to
be SQL_WCHAR, so I think you are totaly right: unixODBC driver manager
conversion may be never used. But if I look at the logs, hex codes used
for 'è' are different for version1 and version2. If conversion is not
involved, I should see the same hex code in the logs, no?

For isql, that the contrary (as you said), it only uses ansi api calls.
But as the logs look different, I've got the feeling logging is done
after the charset conversion, as the hex code are not the same for 'è'
with version1 and version2.

As you can see, with version 2, I still miss something, or my bash
auto-convert on its own. Please help.

Regards, EG

Le 19/09/2016 à 14:05, Nick Gorham a écrit :

> On 15/09/16 16:52, Edouard Gaulué wrote:
>>
>> *** Analyse ***
>>
>> sqlcmd maybe integrates something to detect your encoding and to
>> comply with the connexion one. isql doesn't, nor PHP through PDO.
>> But, if default is set to UTF-8 then those applications do the job.
>
> i think its possible that sqlcmd is reading the input and converting
> in itself into wide characters, and then calling the W functions the
> driver so UTF8 is not being seen by the driver. And likewise with data
> coming back. isql is a simple test tool that is not specific to any
> driver so just takes a string from the terminal and passes it to the
> ansi api calls.
>>
>>
>> *** Questions ***
>>
>> How can read (SELECT) be OK and not write (INSERT, UPDATE) ? That the
>> first thing I found strange. Why applications understand the output
>> should be in UTF-8 whereas thay are said to be in ISO8859-1. Is it a
>> kind of OS feature, knowing you are displaying UTF-8 ?
>
> Not sure, I would turn on unixODBC logging and see what the app is
> doing with the driver.
>>
>> As far as I understand, --with-iconv-char-enc=UTF-8 changes the
>> default character encoding but it can be overrided by
>> directives/options, if implemented. Is this true?
>>
>> If not, what is the risk of compiling with
>> --with-iconv-char-enc=UTF-8 ? on a UTF-8 OS ?
>
> Normally none. The only time the driver manager will use that info is
> when it needs to convert from wide to ansi and vice versa. So for
> example if the driver only has the W functions, and the application
> calls the A points, the the driver manager will call teh W function on
> the applications behalf converting the data using the selected encoding.
>
> I am not sure about the MS driver, but the Easysoft SQL Server driver
> has the ability to set the client side encoding, so the driver knows
> 1. Client character set, 2. Server character set (from the server
> info), so can convert correctly from 1 to 2, and back.
>

_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: Work arround Linux Debian, Microsoft SQL server ODBC driver and charset (ISO8859, UTF8, UCS2)

Nick Gorham-2
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
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support