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: James K. Lowden <jklowden AT speakeasy.org>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Subject: RE: DBLIB Unit Tests failing again
  • Date: Thu, 12 Sep 2002 23:32:53 -0400


On Fri, 13 Sep 2002 09:55:58 +0800, "Varley, David(CBorn at Alcoa)"
<David.Varley AT alcoa.com.au> wrote:

> I've done some testing using clean builds, latest CVS code,
> on Tru64 and x86 Linux, different versions of tds. The Linux
> and Tru64 code seem to have the same result.
>
> tds
> 4.2 Crashes SQL Server !!!
> 5.0 Drops connection and loops, filling log file
> 7.0 Works. (Well, claims to, more later!)
> 8.0 Hangs

Hmm. Which one would you recommend? :(

> This is using dblib t0016, t0017 is pretty much the same
>
> 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.
>
> Using tds 7.0, t0017 doesn't crash, but balks at allocating
> 2147482647 bytes of memory!

Thank you for boiling that down, David. That definitely gives us
something to sink our teeth into.

I don't have access to a Microsoft server, so I test with Sybase. I'm
hoping billg AT microsoft.com will swoop down and plunk a server in my living
room, with best wishes for FreeTDS. Or that someone will give me access
to one over the net. Someone did, actually, but then he dropped out of
sight....

Bill Thompson, who wrote the bcp stuff, returns next week. It worked for
him, so there may be Endianism involved. It would be worthwhile to try
strategically placed bcp_done() calls, though, wrt the crashing.

> Now, some unrelated configuration strangeness...
> I'm building from the one source tree, into parallel object
> trees for Linux and Tru64. The lastest source, into completely
> empty build directorys, gives strangely different results.
> On the Linux system, the extra files are not copies across by
> the make. This includes PWD, the data.bin and txxx.in files, and
> the freetds.conf files. I had to give "make all-redirect" and
> "make install-data-local" commands to copy this data.
> On the Tru64 system these were copied as part of the normal make.
> This used to work on Linux.

There are some ill-founded assumptions in our autotool stuff that you'll
always run "./configure" (intermingling object code in the source tree).
I stumbled across that, too, trying to follow the advice in the autotools
book. If you say something like "../freetds/configure", it should work
and won't.

Again, thanks for point this out. It's something I mean to address.

> Now on the Tru64 system, the first time you do a top level make, it
> gets through just about everything, then spits out what looks like
> several pages of source, complains of a "gawk syntax error", and quits.
> If you try "make" again, it runs through without actually building
> anything else, and appears to be quite happy. I'm assuming this is
> a documentation build problem, the man pages are created with zero
> size.

Thanks for the PR. Without looking, I know the suspect (I should work for
John Ashcroft!). The doc/Makefile looks for "./txt2man", which is a
freely available gawk script. Including it in our CVS and insisting it be
in the current directory were both hacks to finish 0.60.

What should happen is what happens with jade: we should see if there is a
txt2man installed, and use it if so, else just skip the manpage
generation. IOW, CVS users shouldn't have to have doc building tools, but
if they do, they should be able to generate docs.

Nobody on this project is an autotool guru, and sometimes it shows. :/

Regards,

--jkl






Archive powered by MHonArc 2.6.24.

Top of Page