Skip to Content.
Sympa Menu

freetds - Re: DBD-Sybase: Re: number of rows affected with freetds

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Bob Kline <bkline AT rksystems.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: DBD-Sybase: Re: number of rows affected with freetds
  • Date: Mon, 17 Jul 2000 21:36:51 -0400 (EDT)


On Mon, 17 Jul 2000, Daniel Bruce Lynes wrote:

> On Mon, 17 Jul 2000, Bob Kline wrote:
>
> > Edmund Mergl:
> > FreeTDS does not report rows affected correctly.
> >
> > Daniel Bruce Lynes:
> > ODBC uses freetds libraries and works fine. Bug in DBD?
> >
> > Bob Kline:
> > Doubtful, since DBD works fine with Sybase libs.
> >
> > Edmund:
> > I assumed so, but I might be wrong.
> >
> > Sorry for the heavy paraphrasing, but the thread was getting a little
> > unwieldy. :->}
> >
> > I think the weakness in the theory that since ODBC works fine we should
> > look for the cause of the problem in DBD is that -- unlike the ODBC
> > driver, which sits directly on top of the tds library -- DBD has another
> > layer between it and the tds calls, namely ctlib. That's where I would
> > suggest looking first.
>
> Ah...ok...I didn't realize there was another layer in there...that's
> why I suggested DBD.

No problem.

I took a look myself at the ctlib code. According to the Sybase
documentation, a call to ct_res_info with CS_ROW_COUNT as the second
argument (CS_INT type) is supposed to obtain "The number of rows
affected by the current command." And it looks as if the DBD driver has
a call to ct_res_info with that argument, expecting the documented
result. However, the freetds version of ctlib is pulling the value from
the row_count member of the TDSRESULTINFO structure (which holds the
number of rows in a result set) instead of from the rows_affected member
of the TDSSOCKET structure (whose name makes its purpose clear). This
is sounding like a promising candidate for the cause of at least part of
the problem. What do you think, Brian?

However, that's not the only thing I found. I also noticed that even if
that problem were fixed, it doesn't appear as the call to ct_res_info
would get invoked, because the DBD C code where this would happen is in
a loop (see st_next_result() in dbdimp.c) whose test reads:

while ((retcode = ct_results(cmd, &restype)) == CS_SUCCEED) { ... }

and the first call to ct_results gets back CS_END_RESULTS instead of
CS_SUCCEED so the imp_sth->numRows value is left as it was initialized:
as -1.

So it looks like there may be two problems that need fixing. I'm not
sure where the second problem should be fixed, but it's tempting to
think that if the loop referred to above were altered so that its test
continued:

|| retcode == CS_END_RESULTS) { ....

this would fix the original poster's problem (assuming the first bug
also got fixed).

--
Bob Kline
mailto:bkline AT rksystems.com
http://www.rksystems.com





Archive powered by MHonArc 2.6.24.

Top of Page