FreeTDS Development Group

[Tom May <tom AT go2net.com>]

Brian Bruns <camber AT umcc.ais.org> writes:

> On Thu, 11 Feb 1999, Dmitry Melekhov wrote:
> 
> > Hi!
> > 
> > ->Ok, I think I've tracked down the problem, the row buffering version of
> > >DBLASTROW() has some incorrect behaviour (it was returning the number of
> > >rows in the row buffer instead of the total number of rows returned from
> > >the server). I've checked a new version into CVS and things seem good. 
> > >
> > >Please let me know how this works for you.
> > 
> > 
> > :(
> > Bug is still here.
> > 
> > There is no such problem with DBD::FreeTDS, 
> > so this bug is in dblib implementation
> > 
> Yeah, more specifically it is a bug in the row buffering code of dblib.
> DBD doesn't really have such a beast, so it is safe.  A work around is to
> comment all calls to dbsetopt() and dbclrbuf() in functions/sybase.c in
> php3 and rebuild. I've found that it core dumps on me depending on the
> query during a malloc which is very strange. I'm going to have to take a
> deep look at row buffering this weekend. 
> 
> BTW, PHP doesn't actually require row buffering, the reason it is coded
> that way is somewhat of a mystery to me.

I can think of a few reasons:

1. It allows you to do a select on a connection and then re-use that
   connection for another select before reading all the result rows at
   the php level.

2. If the php call to do the query succeeds then you know you can get
   all the rows without further error so it makes error handling
   simpler and avoids the problem where you write N lines of results
   to a web page before getting a database error.

Note that snarfing all the rows in an application like PHP is not a
big deal because given that we're trying to create a web page, the
number of rows is probably not enormous.

Tom.