FreeTDS Development Group

["Mike C." <mcbp223 AT yahoo.com>]

> On Fri, 14 May 2004, James K. Lowden wrote
> 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.

How about defining the callbacks in an oledb-like manner, i.e. if you want
to expose your data store, you can "implement a set of interfaces".
As linked servers go, you can implement
- a table provider, where you offer only basic table access;
- an index provider, which the supposed query engine can use to optimize
queries;
- a command provider, if you want to expose stored procedures as well, and
to understand SQL independently of the said server framework.

I wrote an oledb provider too few years ago, and some of my conclusions are:
- oledb is very flexible, and you have freedom when choosing which features
you want to implement;
- it is very hard to debug, especially for heterogeneous queries (aka linked
servers), and here comes one of the advantages of TDS as an access way, you
can visualize what is going on between the client and the server with a
packet sniffer; with oledb is too much guess work.
- if I had to implement a server framework, I would use most of the oledb
specs, with reserves on property passing and feature discovery. Lots of work
also in making the spec easier to implement by the novice programmer.

BTW, did anybody made Brian's MDB tools accessible through TDS?

Mike