FreeTDS Development Group

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

Sharan Rao wrote:
> We have our own C++ abstraction layer 
> for implementing drivers ( current support for MySQL, Postgres to name a
> 
> few ), with support for cursors in our abstraction. We were looking at
> db-lib  but we don't really need cursor support at that level. 
>  So we were thinking whether we should instead use the lower level
> libtds api. 
Hi Sharan, 

Use db-lib.  Definitely.  It's supported, documented by both us and the
vendors, and stable.  Also you'll find many examples in the distribution. 


The FreeTDS db-lib implementation doesn't support client-side cursors or
"browse mode" and probably never will.  The normal way db-lib is used
doesn't require them.  

A TDS server sends rows to the client as they're produced.  The client
APIs all have a forward-only read-next-row function; in db-lib it's called
dbnextrow().  That's the workhorse for retrieving data. 

There are two things about db-lib that will challenge your abstraction
layer:  

1.  Error handling.  Errors arise in two places: the library and the
server.  db-lib applications learn about the details of an error by
providing callback functions, also known as handlers.  Without handlers,
when a called function fails the application will have no information
about why.  These handlers are connection-independent i.e., there is one
for all connections belonging to a process.  

2.  One statement at a time.  This is really a property of TDS.  While
reading results, it is not possible to issue another query.  All results
must be read -- the pipe must be empty -- before the next query can be
sent to the server.  Other APIs multiplex the connection; sometimes each
query is assigned a "statement" handle.  db-lib has no such.  If you need,
say, to execute a query for each row fetched, you need two connections.  

If you have further questions, you know where to send them.  

HTH.  

--jkl