FreeTDS Development Group

[Sebastien FLAESCH <sf AT 4js.com>]

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