FreeTDS Development Group

["Bill Thompson" <thompbil AT exchange.uk.ml.com>]

Hi Guys,

I've had a quick look at the issues relating to the t0016 program, which
tests aspects of the bcp functionality.

1) I think it is right that we trap TDS protocol 4.2 at the outset and
error accordingly. I would suggest we do this in bcp_init(), but I'm open
to suggestions. I can't immediately see a neat way of trapping TDS
protocol 5.0 being used against a SQL Server database, or 7.0/8.0 being
used against Sybase for that matter. perhaps we could put our heads
together on this one. I know that the login protocol is to "negotiate" a
protocol version with the server, but I don't *think* we do this in
freetds. Perhaps we should....

> 
> t0016 claims to work, but the input and output are different,
> I've attached them here. The out file null-filled as well as
> having the wrong floats, which doesn't show on a simple cat
> of the file.

There are several issues here. I had a look at the input and output files
from David and notice the following:

1) I can't see any evidence of the out file being "null filled" - it looks
OK to me.

2) The third column (which is *numeric* not float ) has clearly become
corrupted somewhere along the line. I am sure this is an endian issue. I
don't have the capability to test a little endian client, so I'll need
some help. It would be really useful to know if the column became
corrupted on the bcp "in" or bcp "out". I think the dblib0016 table
persists after the test program has been run. David, perhaps you could
tell me if the data in the database is corrupt ?

3) The date formats are different - the output format excludes the seconds
and milliseconds, which is not acceptable. This issue goes back a *long*
way :-). I think you must have defined a date format in your freetds.conf
, which the dblib convert function picks up. I think I'm going to have to
hardwire the bcp functions so that they always output dates in the
"complete" format.

> 
> Using tds 7.0, t0017 doesn't crash, but baulks at allocating
> 2147482647 bytes of memory!
> 

Yup. As I may have said somewhere else, the new bcp functions don't handle
blob data yet. I'll get working on that soon. Essentially what's happening
is that the bcp function says "what datatype am I trying to import, and
how much space do I need to read in the data from the file?". Text fields
in SQL server 2K can be up to 2Gb in length, hence the problem...


Bill