Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Bug #805 CVS version of DB_DataObject causes some find() fetch() loops to stop short
Submitted: 2004-02-20 00:02 UTC
From: justinpatrin Assigned:
Status: Suspended Package: DB_DataObject
PHP Version: 4.3.3 OS: Linux
Roadmaps: (Not assigned)    

 [2004-02-20 00:02 UTC] justinpatrin
Description: ------------ I tried the newest CVS version and it seems to be stopping one of my find() fetch() loops after one record. Sometimes it works, sometimes not. find() returns the correct number of matches, but fetch() gives no result the second time around. I've looked at a diff and tried to try commenting things out but nothing has worked so far. I will keep trying. Reproduce code: --------------- A simple piece of code will not reproduce this (at least, not that I have found). Expected result: ---------------- fetch() loops through all records Actual result: -------------- fetch() gives one record and returns false the second time it is called


 [2004-02-20 00:12 UTC] papercrane-2 at reversefold dot com
Of course, it was in the fetch() function. If I comment out the new line: unset($_DB_DATAOBJECT['RESULTS'][$this->_DB_resultid]); Everything works as it did before.
 [2004-02-21 09:20 UTC] alan_k
can you try cvs again. - the unset should only happen when fetchRow returns NULL == the last record.. If it's happening before, then something else is wrong...
 [2004-06-28 09:49 UTC] alan_k
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.
 [2004-08-09 14:12 UTC] evrim at core dot gen dot tr
we'r having the same problem although it's not seem to be reproducable. fetchRow() return null, debug string says: Last data fetch'd in X seconds and thats all. Version info: DB_DataObjects: 1.7.1 PHP:dev-php/php-4.3.8 on a Gentoo box. I haven't even tried to debug my code since it was working w/ old versions of pear for 1 year. *********** We've solved our problem using "keep_query_after_fetch = 1" configuration parameter. *********** Have a nice day (cos' it ruined ours)
 [2004-08-09 17:56 UTC] justinpatrin
Hmmm, been a while since I looked at this bug. I don't remember seeing a NoF e-mail...oh well. I have no idea what piece of code was failing with this. I don't seem (at first glance) to have the problem with v1.7.1. Evrim: what does your code look like that's failing? Maybe it would help to job my memory. I do have a question for Alan, though. While looking through the code, I saw this at the end of fetch(): if (isset($this->_query) && !empty($_DB_DATAOBJECT['CONFIG']['keep_query_after_fetch'])) { unset($this->_query); } This doesn't make sense to me. The config options says to keep the query, and yet if it's set to 1 (!empty()), then the query is unset. Is this right?
 [2004-08-11 06:44 UTC] alan_k
the keep_query_after_fetch has been changed - I guess that crept in when I got rid of the @silencers. This one probably can be closed if it cant be reproduced with 1.7.1 Regards Alan
 [2004-08-11 07:24 UTC] justinpatrin
That's the problem, I don't remember what code had the problem. I'm hoping the other commenter sends some real code.
 [2004-08-12 04:54 UTC] alan_k
suspending until it can be reproduced.