Skip to Content.
Sympa Menu

freetds - RE: [freetds] FreeTDS 0.64.dev.2005041 dblib rpc failure

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] FreeTDS 0.64.dev.2005041 dblib rpc failure
  • Date: Thu, 14 Apr 2005 09:16:22 +0100

Hey Liam,

we've tidied things up a lot recently in db-library.
In particular the dbresults/dbnextrow functionality was re-written.

Some behaviours are, as a consequence, a bit less "slack".

You are falling foul of some validation which is enforcing the
principle contained herein...

from SQL Server BOL
(find dbnextrow in index then read "Accessing Result rows"):

"After all result rows have been returned, the final call to dbnextrow
returns the NO_MORE_ROWS indication.
You must continue calling dbnextrow until it returns NO_MORE_ROWS,
even if you know that the query produces only one result row."

or From the Sybase documentation for dbnextrow():

"If it chooses to process the results, an application can either:
* Process all result rows by calling dbnextrow in a loop until
it returns NO_MORE_ROWS. After NO_MORE_ROWS is returned,
the application can call dbresults again to set up the next
result set (if any) for processing.

* Process some result rows by calling dbnextrow, and then cancel
the remaining result rows by calling dbcancel (to cancel all
results from the command batch or RPC call) or dbcanquery
(to cancel only the results associated with the last dbresults
call).

An application must either cancel or process all result rows."


HTH,

Bill



-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of liam AT inodes.org
Sent: 14 April 2005 01:40
To: FreeTDS Development Group
Subject: Re: [freetds] FreeTDS 0.64.dev.2005041 dblib rpc failure


On Wed, Apr 13, 2005 at 02:19:01PM +0100, Thompson, Bill D (London)
wrote:

> would need a TDSDUMP to see why you're getting the results pending
> message,

Attached.

> but I can see an error in your code.

I've moved the dbhasretstat() to after the while(debresults()). The
TDSDUMP attached is of the modified code.

That is, the testcase now looks like:

...

if (dbsqlok(dbproc) == FAIL) {
dbcancel(dbproc);
dbclose(dbproc);
dbloginfree(login);
return 1;
}

while (dbresults(dbproc) != NO_MORE_RESULTS) {
dbbind(dbproc, 1, INTBIND,
(DBINT) 0, (BYTE *) &value);
dbnextrow(dbproc);
}

if (dbhasretstat(dbproc) == TRUE) {
if (dbretstatus(dbproc) != 0) {
dbcancel(dbproc);
return 0;
}
}

dbcancel(dbproc);

...

This all worked on 0.63 so irrespective of API calling conventions,
something appears to be wrong!

Any ideas?

Cheers.
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain or
redistribute it. Click here for important additional terms relating to this
e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page