FreeTDS Development Group

["Joseph Geiser" <joe AT mail.paravisions.com>]

> On Mon, 26 Jul 2004 David Keith <dkeith AT logisticshealth.com> wrote:
> > I've been trying to track down a problem between Kylix, ODBCExpress,
> > AstaIO, unixODBC, freeTDS and MS SQL 2K. Looks like freeTDS may be the
> > culprit, although I'm not completly certain.  I'm attempting to execute
> > a stored procedure that has input params and returns one output param.
> > If I don't explicitly start/commit/end the transaction, I get an error,
> > here's a snippet from the freetds.log:
> ...

and then Jim writes:
> A little more of the above log might help.  I'd suspect two threads
> sharing a connection.  As far as the server's concerned, there are no
> threads.  There are only connections, and each connection must finish
> reading its results before initiating another query.  Two threads not
> cooperating in their use of a connection could result in the
> 20019 error.

One thing David may wish to try before throwing his hands up is to configure
SQL Server to use both Threads and Fibers.  We use fibers here and have not
had this problem at all -- and the server is hit a lot from both Cold Fusion
MX 6.1 as well as PHP, both of which are multi-threaded servers.

To prove this out before posting this, I switched a crash-n-burn box back to
threads only (no fibers) and what Jim writes above takes over... each
"connection" is unique on its own within a process, and the benefits of
multi-threading are trashed.  Re-enabling the use of Fibers on the SQL
Server box produced a substantial performance boost both with executing
queries and executing SPs with Input/Output parms, as well as returning
resultsets.

HTH - Cheers,
Joe