FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

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
>