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: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: DBD-Sybase: Re: number of rows affected with freetds
  • Date: Tue, 18 Jul 2000 18:02:25 -0400 (EDT)




On Mon, 17 Jul 2000, Bob Kline wrote:

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

An old bug come back to bite us :-) The problem is basically that we
orginally had row_count as part of a result set, but not all queries that
affect rows have result sets, so row_count is a simple increment of the rows
present and rows_affected comes from the TDS_DONE token. Obviously ctlib
never got fixed ;-)

Note: I'm saying all this from memory so I might not be 100% correct.

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
>
>
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
>
>





Archive powered by MHonArc 2.6.24.

Top of Page