[freetds] no conversion changes...
James K. Lowden
jklowden at freetds.org
Thu Sep 18 15:41:02 EDT 2008
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
> 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:
#define SQLExecDirect SQLExecDirectW
> > 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."
> > 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).
> 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
> 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.
More information about the FreeTDS