FreeTDS Development Group

[Igor Korot <ikorot AT earthlink.net>]

Hi,
This is the reply from the iODBC maintainer.
Sebastien, James and Freddy - FYI.

It is an addition to the unixODBC E-mail I sent earlier.

-----Forwarded Message-----
>From: Patrick van Kleef <iodbc AT openlinksw.com>
>Sent: Aug 21, 2008 6:33 PM
>To: Igor Korot <ikorot AT earthlink.net>
>Subject: Re: [Iodbc-list] SQLWCHAR: what it resolves to?
>
>Hi Igor,
>
>
>> 1. Is there a macro which I can check on compile time that will  
>> indicate that iODBC
>> is installed? Does it include a version number?
>
>There are no special version settings at compile time in sql.h to  
>switch between driver managers. There is only the ODBCVER to denote  
>what version/level of ODBC is supported.
>
>However there are several methods you can use to determine at  
>configure or compile time what to use:
>
>1. In configure.in you can make a small check that calculates the  
>sizeof(SQLWCHAR)
>
>2. In configure.in you need to make checks anyway for which driver  
>manager to use,
>    and where it is installed. I can give you a code fragment that  
>can detect any
>    of the unixodbc, iodbc and the commercial datadirect driver  
>manager (should you
>    want to support that too). I can include a check for item 1 for  
>you to use too.
>
>3. There are certain extension defines in every driver manager that  
>can be checked
>    using information from sql.h, sqlext.h etc.
>

But you guys probably already knows about this... ;-)

>
>> 2. What SQLWCHAR currently (in current stable version of iODBC)  
>> resolves to?
>
>It resolves to wchar_t as this is what other driver managers on Unix  
>used at the time we built Unicode support.
>
>Problem is that Microsoft never officially documented any of this  
>driver manager behaviour in proper detail and its behaviour changed  
>radically between earlier versions of ODBC and ODBC 3.52.
>
>Microsoft used a 2 byte wchar_t in win32 api which originally was  
>encoded in UCS-2 (Win95) but with more recent windows versions  
>(NT2000, XP, Vista) was changed to hold UTF-16LE (a decision that not  
>everyone is completely happy with).
>
>Most Unix machines have a 4 byte wchar_t and the few C library  
>functions like wcslen etc all work based on that wchar_t definition,  
>even printf etc work using %S for wchar_t strings on all platforms we  
>support. So like many driver managers at the time we decided to use  
>best use the native wchar_t format.
>
>Our drivers convert the internal data retrieved from the database  
>backend to native wchar_t on the target platform, which works very  
>well for all the platforms that we support. This means that on most  
>systems you can use things like:
>
>     SQLPrepare (hstmt, L"SELECT * FROM ACCOUNT", SQL_NTS);
>
>and have your compiler do the right thing.
>
>
>> 3. What SQLWCHAR will be resolved in the future, and what version  
>> this change is planning to go in?
>
I got a reply to this question but asked to keep the answer to myself
as the design is not finalize yet and the developer still need to do some
researching. But from what I read, he thinks of letting the app to pass
the string and iODBC DM will pick up proper encoding.

Hopefully this information will help you guys.

Thank you.