FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il giorno lun, 19/04/2010 alle 09.57 -0400, jklowden AT schemamania.org ha
scritto:
> On Mon, Apr 19, 2010 at 10:05:45AM +0200, Frediano Ziglio wrote:
> > 2010/4/18 James K. Lowden <jklowden AT freetds.org>:
> > > johnrgavin AT att.net 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