FreeTDS Development Group

["Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>]

Thanks Bill, I had a quick look, comments below. I'll try to look into
it more tomorrow if I get a spare minute.

David


> From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> Sent: Monday, 16 September 2002 7:37 PM
> To: TDS Development Group
> Subject: [freetds] RE: DBLIB Unit Tests failing again
> 
> 
> 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

Thats why I attached the files. Take a look at the .out file with
a hex-editor (eg UltraEdit), or dump it (od -x t0016.out) and you will
see the rows of 00s after each line.

> 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 ?

Sorry, you are right, its numeric. I really wasn't paying a lot of
attention, other than wondering why I couldn't get the unittests to
complete, a bit much on my plate at present!

Anyway, the #dblib0016 is temporary and stored im tembdb, but I changed it
in the test to dblib0016, and found that the numbers in the database are
incorrect, so bcp in must be the culprit.

> 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
> 
> ---
> You are currently subscribed to freetds as: 
> [David.Varley AT alcoa.com.au]
> To unsubscribe, forward this message to 
> $subst('Email.Unsub')
>