Skip to Content.
Sympa Menu

freetds - Re: [freetds] Invalid cursor state error

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Invalid cursor state error
  • Date: Sat, 6 Mar 2004 11:31:45 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page