[freetds] Invalid cursor state error

James K. Lowden jklowden at schemamania.org
Sat Mar 6 11:31:45 EST 2004


On Sat, 06 Mar 2004 12:37:11 +0100, Frediano Ziglio <freddyz77 at tin.it>
wrote:
> ?? store procedure ??
> I think there are two problems. I understood row count problem, but I
> don't know store procedure one... You patch was about SQLRowCount, I
> don't understand where store procedure problems stand..

Yes, there are two problems.  

SQLRowCount() in 0.62.1 fails almost every time.  When SQLMoreResults()
sees TDS_NO_MORE_RESULTS, it sets stmt->dbc->current_statement = NULL.  If
SQLRowCount() is called after that (which is perfectly legitimate), it
sees stmt->dbc->current_statement != hstmt and returns a failure.  Even
though there's no error.  

The second problem is that real errors aren't propogated back to the user.
 To illustrate, modify the stored procedure in
src/odbc/unittests/transaction.c:

	Create Procedure testinsert 
		@value int
	As
	insert into TestTransaction values ( @value )
	select * from TestTransaction
	insert into TestTransaction values ( 'b' )

You will see the 0xAA error packet come back from the server, but
SQLExecDirect() will not return an error to the caller.  

> > To me, it has nothing to do with "rows affected", which, although
> > interesting, is not critical.  What's critical is to be able to call
> > stored procedures and be made aware of any errors transmitted by the
> > server.  
> > 
> 
> It's critical for Perl users, cause DBI::ODBC call SQLRowCount after
> SQLExecDirect/SQLExecute.

That's how I found the problem; I'm using DBD::ODBC.  I don't rely on row
counts, but I do check for errors.  My script was failing because I was
getting an error from SQLRowCount().  Now it's working, but won't detect
errors, which isn't much better.  

--jkl



More information about the FreeTDS mailing list