Skip to Content.
Sympa Menu

freetds - Re: db-lib bcp interface

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: db-lib bcp interface
  • Date: Mon, 26 Nov 2001 07:52:10 -0500 (EST)


On Mon, 26 Nov 2001, Bill Thompson wrote:

> I am currently working on a project to migrate a large Sybase database to
> SQL Server 2000. I have been pursuing a strategy of using Sybase open
> client 11 (db-lib) to connect to SQL server (using dbsetversion() to talk
> TDS 4.2). This works fine apart from the db-lib bcp API which clearly has
> some fundamental problems.
>
> As a consequence I have been experimenting with the FreeTDS dblib bcp (
> the bcp_exec functionality).
> I have discovered some fundamental issues with this which I would like to
> resolve. I would also like to develop this further and possibly complete
> the coding of the remaining functions. I have some questions though.
>
> 1) Whose responsibility is it to resolve the big-endian/little-endian
> question - the client or the server? I notice that the client tells the
> server on the login record which type of architecture it is, so I am
> assuming it is the server's responsibility to convert any raw numeric
> fields. If it is the server's responsibility then we have a problem,
> because my testing shows that SQL server 2000 is assuming that all data is
> little-endian.

The client informs the server on login, and the server does all conversion
to the clients native order. However, TDS 7.0 is a little endian only
protocol, and various implementations of 4.2 have munged things up for big
endian clients. We have therefore added an option 'emulate little endian'
in the freetds.conf file that will make the client speak little endian.

> 2) Does the Client know in any way (apart from the TDS version) what it is
> talking to at the other end ?

Two ways. You may issue a 'select @@version' query and parse it. Or the
login acknowledgement PDU that flows from server -> client after the login
is sent contains a field for identification of the server. Again, you'll
need to know a fair deal about the type of servers possible, but if you
just want to compare a couple types it may work for you...see
tds_process_login_tokens() in src/tds.c for where you would hook into
this (create a field for self reported version in the TDSSOCKET structure,
strdup the field, and make sure to check and free it in
mem.c:tds_free_socket()...I may actually take this on, it could be useful
down the road).

> 3) does anyone have any sort of specification of what the TDS bcp data
> packets look like. I can deduce this from the code, but a spec would help
> :-)

Look at doc/bcp.txt, it's not much but it will give you a basic idea of
the row structure that flow from client to server. Feel free to expand on
it as you go ;-)

> 4) Is anyone else working on this area at present, or planning to ?

I wrote it originally under contract, and someone (forget who) touched it
after me, but no one has touched it in probably over a year.

Good luck and let me know if there is any other questions that come up.

Brian






Archive powered by MHonArc 2.6.24.

Top of Page