Re: Fw: Re: [Iodbc-list] SQLWCHAR: what it resolves to?

Il giorno ven, 22/08/2008 alle 14.00 -0400, Igor Korot ha scritto:
> 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 <[email protected]>
> >Sent: Aug 21, 2008 6:33 PM
> >To: Igor Korot <[email protected]>
> >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... ;-)
> 

Yes, was implemented in 0.63 or 0.62... but if they have better
implementation they are welcome!

> >
> >> 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.
> >
> >

I don't agree 100%, looking at code they use mbstowcs/wcstombs to
convert but they assume only single byte encodings. I downloaded
libiodbc-3.52.6 and you can check this in
_iodbcdm_conv_param_A2W/_iodbcdm_conv_param_W2A, code like

      if (size > 0)
        OPL_W2A(pData, param->data, size);
      ((char*)param->data)[size] = '\0';

assume size characters on input and size bytes on output.

> >> 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.
> 

I readed in unixODBC list that they probably unify SQLWCHAR... honestly
I would prefer wchar_t is iODBC but Nick (unixODBC maintainer) seems to
not agree

freddy77