Skip to Content.
Sympa Menu

freetds - Re: [freetds] no conversion changes...: Unicode with UTF-8 or

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] no conversion changes...: Unicode with UTF-8 or
  • Date: Fri, 19 Sep 2008 10:41:36 +0200

Hi,

Sorry if I don't follow/understand the details...

But from an ODBC programmer point of view, would it mean that if I want to
use the UTF-8 character set, I will need to convert to UCS-2 and use the W
ODBC functions or can I still use UTF-8 (char*) with the non-W functions?

Cheers,
Seb

James K. Lowden wrote:
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
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds






Archive powered by MHonArc 2.6.24.

Top of Page