Skip to Content.
Sympa Menu

freetds - RE: DBLIB Unit Tests failing again

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>
  • To: 'TDS Development Group' <freetds AT franklin.oit.unc.edu>
  • Subject: RE: DBLIB Unit Tests failing again
  • Date: Mon, 16 Sep 2002 20:33:20 +0800



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')
>




Archive powered by MHonArc 2.6.24.

Top of Page