ODBC bcp

Hi all,

I wanted to be able to bulk copy into SQL Server from an ODBC
application, so attached is my *work in progress* attempt at making
this happen, for the purpose of early feedback about the approach.

The only other attempt I can find at doing this was [0], which seemed
extremely hacky and may have required significant code in the user
application. My attempt tries to do it 'properly' and I've been
testing it with an application which builds unaltered on both Windows
and Linux.

The patch steals a large amount of code from dblib/bcp.c but, in
order to give myself an achievable goal, it implements *only* bcp in
from RAM; all of the file I/O stuff has been ripped out. I believe
this is a very sane and useful subset to have because my application
does the bcp as one step of a single larger transaction and hence
needs to use the existing ODBC connection. People wanting the file I/O
bit probably don't have this constraint and hence can just use dblib
or freebcp.

A very useful document is [1] which lists the API differences from
dblib. The most annoying is probably that all errors must go through
SQLGetDiagRec rather than dblib's error handling, which is what
necessitated so much copy-and-paste. A future task is to look at how
this could be rationalized.

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*.
SQLGetInfo(SQL_DRIVER_HDBC) can be used to convert, but that means we
need to find SQLGetInfo. Approaches I've thought of so far are:

1) dlopen(...,RTLD_NOLOAD) with various hard-coded filenames to try to
find which driver manager the application is using

2) dl_iterate_phdr() to look for filenames that look like the driver
manager [this is what's currently in the patch].

3) dlsym(RTLD_DEFAULT,...).

4) Create a gratuitous libtdsodbcbcp.so containing just thunker
functions whose sole purpose is to get out of the way of the default
symbol search path so that method (3) works more reliably.

Microsoft's Windows driver uses (1) because they know there's only one
driver manager. (3) is subject to ordering problems with the symbol
search, but those problems exist anyway at link time so I'm beginning
to think that might be best.

Richard.

[0] http://lists.ibiblio.org/pipermail/freetds/2005q1/018076.html
[1] https://msdn.microsoft.com/en-us/library/ms130924.aspx

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds