Re: Plan to support newer MS SQL Server types

On Tue, Apr 20, 2010 at 03:11:33PM +0200, Frediano Ziglio wrote:
> 2010/4/19  <[email protected]>:
> >
> > So, no matter how I set TDSVER, I never get more than 7.1. :-(
> 
> Mmmm.... are you speaking about binary bindings in dblib ?? 

dbbind(), BINARYBIND, yes.  Doesn't work for UCS-2 columns today.
The only way to make it work is to delay calling iconv(3) until
binding (and skipping it for BINARYBIND).  

> Currently
> odbc works this way. Another way is to convert utf-16 to "normal"
> characters directly in token.c (like (N)TEXT and normal (N)VARCHAR)
> but there is no function to convert in a chunked way and after
> discovering text problem with protocol 7.2 I just decided to limit
> ctlib/dblib protocol to 7.1. dblib won't never support stuff like MARS
> and UDT for .NET objects so there is no improves adding support for
> 7.2... 

The vendors have stopped supporting db-lib, but we don't have
to.  We can add functionality to keep up with new server features.  

dbmoretext() could be written to operate differently on 7.2
connections.  It's equivalent to SQLGetData for long text data,
and the natural way for db-lib to handle varchar(max).  (Your
7.1-limit fix is very good for the time being, though.)

There's also BCP to consider.  Until we add bcp to ODBC, we're
going to have to keep db-lib up to date if freebcp is to remain
viable.  

I'm deeply skeptical about MARS.  I see very little advantage --
and some tcp/ip disadvantage -- to multiplexing a connection. 
The TDS Way has always been to use two connections, which works
quite well.  MARS afaict is an answer to an ignorant market about
"features" and "limitations".  

I don't think db-lib has to support MARS, although I wouldn't
object if someone wanted to do it.  At a minimum, db-lib needs to
support all server datatypes.  Otherwise, as you say, its future
would be limited.  

--jkl