Re: Plan to support newer MS SQL Server types

Il giorno lun, 19/04/2010 alle 09.57 -0400, [email protected] ha
scritto:
> On Mon, Apr 19, 2010 at 10:05:45AM +0200, Frediano Ziglio wrote:
> > 2010/4/18 James K. Lowden <[email protected]>:
> > > [email protected] wrote:
> > >>
> > >> The other thing is that if I select from a DATE or TIME (not datetime)
> > >> column on a SQL Server 2008R2 database, inspecting the column headers
> > >> returned in the RESULT SET tells me they are returned to the client as
> > >> CHAR. ?These would be TDS 7.3 types, so if you are telling me you have
> > >> 7.2 covered, that would explain this.
> > >
> > > http://msdn.microsoft.com/en-us/library/ms187594(SQL.90).aspx
> > >
> > > As you gathered from the documentation, SQL Sever 2000 datatypes are all
> > > supported in 0.82, and most 2005 datatypes are supported in the current
> > > snapshot.
> > 
> > Current CVS support protocol 7.2 under ODBC. Either dblib, ctlib and
> > even tsql do not support 7.2. This due to conversion problems using
> > VARCHAR/CHAR(MAX). Probably tsql and ctlib will support (in a
> > unplanned future) 7.2. Probably dblib hardly will support 7.2 due to
> > some incompatibility with LOBs.
> 
> ??  For db-lib connections, the server converts varchar(max) to TEXT (type 35).  Then the db-lib API can deal with it either by binding it as a string or with dbmoretext().  I don't see any problem with that as long as the server continues to support it in that way.   
> 

Yes, this is true with MS dblib cause MS dblib use only protocol 4.2. We
support protocol up to 7.1 under dblib :)

> > > I'm not too sure about the variant datatype, though.
> > 
> > Surely supported by ODBC, recently fixed in tsql... I don't know about
> > ctlib and dblib :(
> 
> Not a priority for me because I don't see the point.  If we know how to convert it to C data types, there's no reason dbbind() couldn't handle it naturally.  But someone has to care.  
> 
> In the SQL Server 2000 documentation even Microsoft punts: 
> 
> 	"ODBC does not fully support sql_variant. Hence, queries of sql_variant columns are returned as binary data when using Microsoft OLE DB Provider for ODBC (MSDASQL). For example, an sql_variant column containing the character string data 'PS2091' is returned as 0x505332303931."  
> 	
> In 2005 they do better:
> 
> 	"ODBC does not have a concept of variant types, limiting the use of the sql_variant data type with an ODBC driver in SQL Server. In SQL Server, if binding is specified, the sql_variant data type must be bound to one of the documented ODBC data types. SQL_CA_SS_VARIANT_TYPE, a new attribute specific to the SQL Native Client ODBC driver, returns the data type of an instance in the sql_variant column to the user."
> 	
> I guess that means that if your variant stores a string on the server, it can bound to a string on the client.  
> 

In 0.82 libTDS does not support variant replacing it with NULLs... CVS
version store and manage data. Yes, your have to bound to specific data
in order to fetch but is supported 

> > It's not that hard to add support for this kind of types is harder to
> > support MARS (using MARS transaction protocol change a bit and also
> > libTDS needs changes). Also we do not support binary XML... but nobody
> > seems to care about it :) (me too!).
> 
> The FreeTDS project doesn't have Microsoft's resources to extend the API indefinitely.  Resources appear quite readily when the need arises, but many odd corners don't serve any real need except the vendor's.  
> 
> That's consistent, by the way, with the IETF and "rough consensus and running code".  Standards (and APIs) developed far ahead of implementations -- as vendor-developed APIs must be -- run the risk of being overengineered and underutilized or ignored.  
> 
> If the FreeTDS community is satisfied with the breadth of the implementation -- if it meets their needs -- then I for one am content to leave the useless (or marginal) parts undone.  There is more important work and nonwork to be done.  
> 
> I don't pretend FreeTDS is perfect. For me, though, at this point it's a matter of quality more than features.  I'll hang up my uniform when it works easily and flawlessly.  
> 

Agreed. I think most requested are MARS and SQL 2008 types.

freddy77