FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Vadym Kononenko wrote:
> Yes, this is fine. But this driver (dbd-tds) is mostly done.
> And I think that way described in my previous letter:
>   "But I think it could be better to use the tds layer for my task.
>    Because DBD is a database-dependend layer of the DBI architecture, 
>    I hope You know about. So DBD should be a link between DBI calls and 
>    database-dependend CLI libraries (libtds?).
>    [userApp] <-> [libDBI] <-> [DBD-FreeTDS shared object (driver)] <-> 
>    [libtds] <=TDS=> [MSSQL/Sybase DBMS]"
> is better than
> [userApp] <-> [libDBI] <-> [DBD-FreeTDS shared object (driver)] <->
> [ct-lib or  any other] <-> [libtds] <=TDS=> [MSSQL/Sybase DBMS]

Vadym, 

I know what it's like to have something mostly completed, only to be
discouraged near the end.  Bill and I don't want to discourage you; we
want you to succeed.  

Architecturally, you're thinking of libtds as the TDS library and ct-lib
as the "driver".  Because libdbi is itself a driver, you're questioning
why you'd write a "driver to a driver".  

What's a driver?  To me, FWIW, a driver has a well specified, standardized
interface, allowing drop-in replacements.  DBI specifies such an
interface, so does ODBC.  By that definition, ct-lib and db-lib aren't
drivers[1].  They're callable libraries.  They are safe ways to generate
and use a TDS connection.  

libtds, in contrast, is not even a very good library, from the point of
view that it doesn't support atomic actions on the TDS stream (doesn't
read and write whole packets).  To use it "correctly", you have to be
knowledgeable about the TDS protocol and maintain state information for
it.  That's a lot to ask of someone not working directly on the project.  

In practical terms, the question you first asked would be one of many
before you had reliable driver.  You might get something to connect and
move some data, but a lot of corners would be dark.  For example, you'd
have to deal with protocol differences between Sybase and Microsoft (or
between Microsoft and Microsoft).  libtds doesn't shield you from them. 
Even if we never changed the interface, your driver would be unable to
fully use Microsoft's next server release.  

The fact that you got as far as you did tells me you're a competent
programmer.  Besides learning the API, converting to ct-lib will be mostly
a matter of stripping out code you don't need and deciding how to handle
errors.  It's one of those learning curves with a hump at the front that
gets easier as you go along.  Please don't hesitate to ask questions here
if you need help.  

Regards, 

--jkl

[1] Sybase specified ct-lib in generic terms, evidently hoping/planning to
make it a standard API for database connectivity.  But Sybase never
offered ct-lib drivers for other vendors' products, and neither did anyone
else.  All hail the proprietary interface.