FreeTDS Development Group

[jklowden AT schemamania.org]

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.   

> > 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.  

> 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.  

--jkl