Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: Igor Korot <ikorot AT earthlink.net>, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Fw: Re: [Iodbc-list] SQLWCHAR: what it resolves to?
  • Date: Sat, 23 Aug 2008 10:38:47 +0200

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

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






Archive powered by MHonArc 2.6.24.

Top of Page