Skip to Content.
Sympa Menu

freetds - RE: [freetds] A new patch - various fixes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] A new patch - various fixes
  • Date: Wed, 19 Mar 2003 17:28:15 -0500 (EST)


row_count is *OLD*, it has been around since version 0.1 or so I
think...it precedes alot of knowledge about the TDS protocol. Consider it
an evoluntionary vestige. Bill is right in preforming the appendectomy
on this one. I seem to recall a situation where rows affected was not
equal to row_count, but that's been a long while back, and probably isn't
relevant anymore.

Brian

On Wed, 19 Mar 2003, Lowden, James K wrote:

> > From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> > Sent: March 19, 2003 11:15 AM
> >
> > I'm not sure why we are/were maintaining row_count.
> > My guess is we were doing this before we understood how to get the
> > rows_affected count out of the end token.
> > Its incremented in tds_process_row() and is/was accessed only
> > in dbcount, and ct_res_info
>
> Thanks for the explanation, Bill. We probably should rename row_count to
> _nfetched or somesuch, and use it only for logging.
>
> Your patch is committed, with dbcount() trimmed down to the nubbin.
>
> --jkl
>
> > Using the "rows affected" returned in the end token is I'm
> > sure the right way to proceed.
> > Also in the end token is an indication of whether this value
> > is meaningful or not.
> > If the current session has "set nocount on" then the end
> > token tells you
> > that the "rows affected" count is inapplicable.
> > This is also the case if the statement processed is, say a
> > "create table" statement.
> > This allows the programs to distinguish between a meaningful
> > count of 0 (
> > generated by for example a "select * from table where 1 = 2 ")
> > and a meaningless count.
> >
> > We could do away with resinfo->row_count, I reckon, but I
> > left it hanging there just in case...
> >
> > HTH, and thanks for applying the patch so quickly.
> >
> > Bill
> > > -----Original Message-----
> > > From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> > > Sent: 19 March 2003 15:55
> > > To: 'FreeTDS Development Group'
> > > Subject: RE: [freetds] A new patch - various fixes
> > >
> > > > From: Thompson, Bill D (London)
> > [mailto:ThompBil AT exchange.uk.ml.com]
> > > > Sent: March 19, 2003 9:42 AM
> > > >
> > > > I have submitted patch number 706303 to sourceforge
> > >
> > > Thanks, Bill.
> > >
> > > > This patch was built on last nights snapshot.
> > >
> > > And went in very smoothly. :-)
> > >
> > > > 1) small fix to correctly handle/return the "rows
> > affected" count. I
> > > > discovered that sqsh was reporting "rows affected" when
> > it shouldn't -
> > > > specifically if "set nocount on" had been specified.
> > >
> > > There's something I don't understand about your change:
> > >
> > > @@ -2063,15 +2063,10 @@
> > > DBINT
> > > dbcount(DBPROCESS * dbproc)
> > > {
> > > -TDSRESULTINFO *resinfo;
> > > TDSSOCKET *tds;
> > >
> > > tds = (TDSSOCKET *) dbproc->tds_socket;
> > > - resinfo = tds->res_info;
> > > - if (resinfo)
> > > - return resinfo->row_count;
> > > - else
> > > - return tds->rows_affected;
> > > + return tds->rows_affected;
> > > }
> > >
> > > and similar in ct.c. Is row_count now superfluous?
> > dbcount() should
> > > return
> > > the count of rows returned on a select statement. I can't
> > see that you're
> > > stuffing that value into rows_affected instead.
> > >
> > > I've reviewed the patch and applied it, but I'd like to hold off the
> > > commit
> > > until I hear from you on this. Sorry to catch you at the
> > end of the day.
> > >
> > >
> > > Regards,
> > >
> > > --jkl
> > >
> > >
> > > The information contained in this transmission may contain
> > privileged and
> > > confidential information and is intended only for the use
> > of the person(s)
> > > named above. If you are not the intended recipient, or an
> > employee or
> > > agent
> > > responsible for delivering this message to the intended
> > recipient, any
> > > review, dissemination, distribution or duplication of this
> > communication
> > > is
> > > strictly prohibited. If you are not the intended recipient,
> > please contact
> > > the sender immediately by reply e-mail and destroy all copies of the
> > > original message. Please note that we do not accept account
> > orders and/or
> > > instructions by e-mail, and therefore will not be
> > responsible for carrying
> > > out such orders and/or instructions.
> > >
> > >
> > > _______________________________________________
> > > FreeTDS mailing list
> > > FreeTDS AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/freetds
> >
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> >
>
>
> The information contained in this transmission may contain privileged and
> confidential information and is intended only for the use of the person(s)
> named above. If you are not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, any
> review, dissemination, distribution or duplication of this communication is
> strictly prohibited. If you are not the intended recipient, please contact
> the sender immediately by reply e-mail and destroy all copies of the
> original message. Please note that we do not accept account orders and/or
> instructions by e-mail, and therefore will not be responsible for carrying
> out such orders and/or instructions.
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>




Archive powered by MHonArc 2.6.24.

Top of Page