Skip to Content.
Sympa Menu

freetds - Re: [freetds] no conversion changes...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] no conversion changes...
  • Date: Thu, 18 Sep 2008 15:41:02 -0400

Frediano Ziglio wrote:
> Il giorno sab, 13/09/2008 alle 16.51 -0400, James K. Lowden ha scritto:
> > First: What do we mean by "wide"? UCS-2? UTF-16? UCS-4? UTF-8? Is
> > it compile-time dependent? Run-time?
>
> It depends from DM... unixODBC use UCS-2 while iODBC use wchar_t
> (usually UCS-4 on Unix.. or not?? I'm not sure, certainly Linux use
> UCS-4). Using unixODBC there is a configuration flags to use wchar_t but
> usually is not enabled

OK, so it's a compile-time setting.

> > I see a
> > reference to a "ODBC 3.5 (or later) Unicode Driver". Is that what
> > we're building?
>
> Yes, in a future (not very far) yes

OK.

> Unicode driver means that all ANSI version have a
> corresponding unicode version (like SQLExecDirectW for SQLExecDirect).
> The change is interpret characters as wide instead of ANSI.

I see. So a Unicode appliction calls SQLExecDirectW, or does a
preprocessor macro convert it, something like:

#if UNICODE
#define SQLExecDirect SQLExecDirectW
#endif

??

> > Fourth: Can you show me the API function call sequence that mixes
> > encodings for a single column?
>
> I never tried but I think reading TEXT/NTEXT with SQLGetData changing
> SQL_C_CHAR/SQL_C_WCHAR for the same column.

The app can call SQLBindCol in between calls to SQLFetch, too:

"A column can be bound, unbound, or rebound at any time, even after
data
has been fetched from the result set. The new binding takes effect the
next time that a function that uses bindings is called."
(http://msdn.microsoft.com/en-us/library/ms711010(VS.85).aspx)

> > Maybe it would be easier to create a BRANCH_UNICODE branch in CVS
>
> I would
> prefer a "from XXX date code is quite broken so if you want to use CVS
> use cvs co -D XXX".

OK. Maybe just a CVS tag UNICODE_BASE or something like that, so we don't
have to remember the date.

As long as db-lib and ct-lib remain useable in CVS HEAD, I'm happy. I
intend to change tds_connect() for example, so broken code would be bad.

> To be sure we could branch and continue working on CVS HEAD, having a
> BRANCH_NOUNICODE. Branch and merging is heavy on CVS, this way main
> changes will go to the no-branch.

We can do that later if HEAD becomes too unstable to use.

> The problem with "convert nearest the wire" is that at the moment libTDS
> fetch data and fill row buffer it doesn't know which encode the client
> wants (SQL_C_CHAR or SQL_C_WCHAR).

Understood.

> All that stuff suggest me "direct binding"...

Right. Convert at the ODBC<->libtds boundary.

> how to implement all new datatypes of mssql2005 and mssql2008 ?? One
> problem with mssql2005 is the VARCHAR(MAX) which can be very large,
> something like SYBLONGCHAR/SYBBLOB of Sybase (still not that supported).

I haven't thought about this very much. I know that for zero-copy, the
client library must provide the target buffer into which libtds places the
data.

> I'm currently filling a table of types with flags (like ascii, unicode,
> fixed and so on) and other informations (varint ms/sybase)

Excellent. You might want "cardinal" type, too.

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page