Skip to Content.
Sympa Menu

freetds - [freetds] Is it possible to start another query on a connection provided that not all rows of a previous select statement are fetched?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Michael Kochetkov" <Michael.Kochetkov AT synartra.com>
  • To: <freetds AT lists.ibiblio.org>
  • Subject: [freetds] Is it possible to start another query on a connection provided that not all rows of a previous select statement are fetched?
  • Date: Thu, 7 Oct 2004 00:01:49 +0400

Hello,
I have encountered the following problem with freetds-0.63.dev.20040824: if
I execute a select query on a connection which returns N records and I call
SQLFetch N or less times then the connection becomes desperately broken.
I.e. all subsequent queries fail with "[FreeTDS][SQL Server]Invalid cursor
state" diagnostics. Calling SQLFetch N+1 times does solve the problem (and
probably SQLMoreResults may help too) but this is unacceptable solution for
us. Frankly speaking, any solution that would require a user to perform a
special clean-up after a query execution to keep a connection alive seems
unacceptable - we have a lot of code and algorithms already that use a
database access framework and know nothing about clean-up problem and
retrieve or abandon rows fetched the way they want. The FreeTDS is planned
to be a part of the back-end for the framework. I would not mind if the sql
statement gets broken but not the connection itself. On the other hand there
is a (lucky) chance I miss something and everything shall work for FreeTDS
the way it does for me on Windows box (MS ODBC driver for MS SQL Server).
So, is it possible to start another query on a connection provided that not
all rows of a previous select statement are fetched? I believe it is
possible with MS ODBC driver.

Thank you in advance,
-
Michael Kochetkov.




  • [freetds] Is it possible to start another query on a connection provided that not all rows of a previous select statement are fetched?, Michael Kochetkov, 10/06/2004

Archive powered by MHonArc 2.6.24.

Top of Page