[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>
> ?? 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
Create Procedure testinsert
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
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.
More information about the FreeTDS