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: Frediano Ziglio <freddy77 AT gmail.com>
  • 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 18:48:59 +0200

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






Archive powered by MHonArc 2.6.24.

Top of Page