Re: no conversion changes...

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