FreeTDS Development Group

["James K. Lowden" <james.k.lowden AT icloud.com>]

On Thu, 12 Mar 2015 19:36:06 +0000
Richard Hughes <cyreve AT gmail.com> wrote:

> The HDBC problem should be discussed. Because the driver manager has
> no idea about the bcp APIs, the first parameter that all the functions
> receive is a driver manager HDBC, not a TDS_DBC*.

Hi Richard, 

Like Frediano, I often wanted to add bcp to ODBC, but never really
needed to.  I'm glad to see someone tackle it.  :-)

I don't see the difficulty in quite the same way you do.  You have a
valid HDBC. It's connected.  There's no rule that says (1) FreeTDS has
to do what Microsoft did, or (2) that the DM has to know about every
function supplied by the driver.  

Because dlopen has already been called, all driver functions,
including any nonstandard functions, are already linked in.  

I think what you really need is the DM's handle to the loaded driver,
i.e. the handle returned by dlopen(2).  If there's no function to
return that, I'd talk it over with the unixODBC folks and see if some
sensible approach doesn't suggest itself.  Either way, I'd hack the DM
to get the handle, map in the functions, and away we go.  

BTW, this link looks useful if you haven't already seen it: 
        https://msdn.microsoft.com/en-us/library/ms130924.aspx

Finally, as a technical matter it's never been clear to me that the
db-lib functions couldn't be used in situ.  Why not have the ODBC
driver call db-lib?  You could construct a fake DBPROCESS structure for
it with the connected socket already in place. Each ODBC call would map
to a db-lib call using the contructed "db-lib connection" using err and
msg handlers to compose buffers to supply to SQLGetDiagRec.  

Most of your work would be to write a "bcp application" in the ODBC
driver (and map that application onto the ODBC bcp functions).  The
only db-lib change would be the magic of the ODBC bcp_init that would
construct a DBPROCESS ab initio from a live, connnected HDBC.  

The advantages of using db-lib to support ODBC in this way are more
important than any asthetic software-architecture concerns.  The bcp
code works very well, and would hardly be changed.  The behavior of
both libraries is near identical, and freebcp exercises exactly the
same code that ODBC does.  The bcp part of the TDS protocol is fiddly,
and if you get it wrong you'll be unceremoniously disconnected.
Really.  No cerermony at all!  And propagating the errors is both
important and a bit tedious.  Both those would make me hesititate to
start moving bcp into libtds.  

It's only software; anything is possible.  Depending on how much time
you want to put in and what you want to get out of it, either choice is
viable.  Just wanted to mention another possibility.  

Regards, 

--jkl