Skip to Content.
Sympa Menu

freetds - Re: FreeBSD 2.2.8, Apache 1.3.4, PHP 3.0.6- core dumped :(

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: FreeBSD 2.2.8, Apache 1.3.4, PHP 3.0.6- core dumped :(
  • Date: Thu, 11 Feb 1999 20:10:07 -0500 (EST)




On 11 Feb 1999, Tom May wrote:

> 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.
>
I guess I should have explained a bit more. PHP does something like:

while (...) {
...
dbnextrow(...);
dbclrbuf(..., DBLASTROW(...)-1);
...
}

So, every time through the loop they clear the row buffer (column contents
are saved off to php elsewhere in the loop), so yes php caches the rows
before returning them to the web page, but they don't seem to use row
buffering to do it. *shrug*

Brian






Archive powered by MHonArc 2.6.24.

Top of Page