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: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Invalid cursor state error
  • Date: Sat, 06 Mar 2004 12:37:11 +0100

Il ven, 2004-03-05 alle 21:13, Lowden, James K ha scritto:
> > From: freddyz77 AT tin.it [mailto:freddyz77 AT tin.it]
> > Sent: March 4, 2004 10:49 AM
> >
> > Problem is multiple statement. Assume you
> > - create 2 statement
> > - issue an update on first statement
> > - issue a select on second statement
> > - you want to read rows changed in first statement.
> >
> > The solution is to cache rows number on first statement
> > (cause rows number
> > on TDSSOCKET get overwritten by second statement).
> > You patch is a workaround and work for single statements.
> > !hstmt test is
> > useless (statement value is already tested in macro).
>
> Hi Freddy,
>
> I'm not absolutely sure we're working on the same problem, but maybe we
> are. All I know is I get (untrue) errors invoking stored procedures with
> 0.62.1, and that with my patch applied I don't see errors that I should
> see.
>

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

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

> I'm ready, willing, and able to work on this. I'd be happy to solve it at
> the expense of correct row counts for now. I'd like to fix the release, if
> at all possible. But I'm not really sure how to attack the problem in a
> way that's consistent with what you have in mind.
>
> I suspect that the error reporting problem is deeper than I first thought.
> I don't see how my patch can prevent error messages from being reported by
> SQLExecDirect(). I think they just aren't reported.
>

I didn't catch you...

> Have you looked into this and do you have any thoughts on the matter?
>

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page