FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

On Sat, 14 Sep 2002 06:47:29 +0800, "Varley, David(CBorn at Alcoa)"
<David.Varley AT alcoa.com.au> wrote:

> 
> My concern was primarily that "make check" could successfully complete,
> as a way to validate operation of CVS head code on different platforms.
> If the dblib tests fail the ODBC tests never even get to run.
> I changed the test DB from JDBC to a local MSQL one when JDBC wasn't
> working, plus its much faster to test locally.
> Default freetds.conf (which keeps popping up in new locations :) has
> tds version = 4.2   I hadn't looked at the bcp manual or even known that
> was what was being tested until the problems started!

This is immediately doable.  No reason the unittests have to crash your
server mindlessly, just check TDSVER and print a warning that
such-and-such combination was not run.  

> Stopping a known-bad configuration crashing the server seems a good
> start, be nice if it gave a warning and still passed the test so others
> could run though. The incorrect data returned from MSQL should be a fail
> still.

There is no easy way yet to query FreeTDS for the protocol version being
employed.  I'll add dbgetversion().  Would you like to patch the tests?  

> Jim, I'd be happy for you to use a test SQLServer DB here, but there's
> be a bit of hacking involved, starting with setting up a Dynamic DNS so
> you could locate us (I've started on this), port-forwarding on the
> firewall to the Server, and then the problems that I'll need to restart
> the Server when FreeTDS crashes it, and I'm going away for a week in a
> week.

Sheezopizzaria!  Well, if you can get all that done, I'd happily crash
your server for a hamburger on Tuesday.  :)

--jkl