FreeTDS Development Group

[Steve Kirkendall <skirkendall AT dsl-only.net>]

"James K. Lowden" <jklowden AT schemamania.org> wrote on Friday, May 14, 2004:
> > I hope to get my altered versions of the server functions cleaned
> > up and submitted this weekend.  That's kind of important, because
> > my available time for this tiny server project has just about ended.
> 
> I guess "tiny" refers to the server?  ;-)

Yes.  I just checked, and it's currently about 5500 lines for the generic
server plus another 400 or so for the C-tree DB interface.  Not counting
generated files such as y.tab.h, of course.  Pretty big for a 3-week
project, but tiny for an SQL server.

> > Do you know what SQL_DATETIME_SUB and INTERVAL_PRECISION
> > should be?  I've had some trouble getting TIMESTAMP data types to
> > display correctly, and they sound like they might be relevant.
> 
> I'm not sure how to answer those questions.  
> 
> http://www.schemamania.org/projects/freetds/build/sp_datatype_info.dump
> 
> That's the log of my query.  Tell me if you need more.  

Very useful.  Thank you.  The highlights of that dump are:

1) There is no "capabilities" token in the login stream.  I thought that
   might be a TDS 5.0-only thing, and this seems to support that idea.

2) While a stored procedure is running, any "done" tokens should use
   token 255 instead of 253.  Also, at the end of the procedure it should
   send a 121 "return status" token (with 0 as the status) followed by a
   254 "done" token.  It's nice to see how all of these tokens fit together.

3) For "timestamp", the SQL_DATETIME_SUB and INTERVAL_PRECISION columns
   in sp_datatype_info's result table are null.  So that probably isn't
   why Crystal Reports is truncating timestamps at 8 characters.  One
   weird thing: your server reports "timestamp" as being generic binary
   (type code -2) instead of ODBC timestamp (type code 11).

> This is quite a cool thing you're doing.  Some years ago, when OLE was
> hot, I wrote an OleDB server: it offered library output as "tables" via
> Microsoft's OleDB libraries and classes.  (Advise: don't bother.)  This
> idea of yours is much more flexible.  In theory, there could be a server
> framework that, with a few well-defined callbacks, could make any data
> store acccessible via TDS.  Many possibilities fall out of that.  

I'll ask whether I can release my little server as open source.  It should
be easy to adapt to other data sources.  It uses just five calls to the
underlying data source:

init()  Opens all files, and for each table it builds an internal 
        description and enrolls that description in the server's
        dictionary.

term()  Closes all files.

cost()  Estimates the time required to scan all rows that have a given
        range of values in a given columns.  (My little server is only
        smart enough to handle single-column keys.)

first() Fetches the first row matching search criteria that were
        previously evaluated via cost().

next()  Fetches the next matching row.

There are some other server-side applications that might be useful.
For example, you could write a fairly small program that accepts TDS
queries and farms them out to multiple *real* SQL servers, for load
balancing.  Updates could be a problem, but certainly there are a lot
of applications that only read data.