Skip to Content.
Sympa Menu

freetds - Re: [freetds] Plan to support newer MS SQL Server types

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: jklowden AT schemamania.org
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Plan to support newer MS SQL Server types
  • Date: Mon, 19 Apr 2010 09:57:13 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page