FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> 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.

It's not broken, it's just busy. Fetch all result or free the statement
and use another and will work.

> 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

Connection it's alive, you have to call SQLFetch + SQLMoreResults till
SQL_NO_DATA or close and reopen statement.

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

MS Box works the same way, many tests in unittests test this behavior
and works using both FreeTDS driver and MS one...

> 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.
> 

You can even use SQLCancel however there can be problems with
transactions. For example calling a store procedure that returns many
results and stopping from fetching data can result in a partial store
execution.

bye
  freddy77