Re: [metabase-dev] numRows in the oracle driver

Hello, On 03/10/2003 06:40 AM, Lukas Smith wrote:

I am having some trouble getting the numRows() method to work like I want it to in the oracle driver. 1) Right now numRows() works the Metabase way of simply fetching all the rows and then returning that number. 2) PEAR works by checking if the last query was the query for which numRows() was called and then doing "SELECT COUNT(*) FROM (".$this->last_query.")";. 1) Was the advantage of not sending off yet another query, which is pretty ugly. But it makes the current while loops in fetchCol() and fetchAll() fail because they rely on the fact that no other method has messed around with the result set. I could fix that by specifying fetchInto the exact row I want. This will result in mysql_data_seek calls in the mysql driver.

Metabase handles this circumstance properly. I am not sure what was lost in your MDB port.

Anyways if all I want is all data and the numbers or rows that is no problem as I can just do fetchCol|All and do a count on the array. But if I first want to check the number of rows and then do a fetchAll() if the number is what I want then I start to run into trouble. FYI: oracle does not return the number of fetched rows because it starts to return rows before it even finished finding all. So whatever the solution for

That is the way most high end databases work, not just Oracle.

numRows it will go a bit against the spirit of the oracle driver anyways (yes I know there is ocifetchstatement() but for several reasons that is not a good alternative and certainly no "solution" to be problem)

Yes, the use of NumberOfRows call is discouraged in Metabase documentation for large result sets because it is slower.

2) Gets rid of the issues if 1) but via an ugly hack. Anyone who cares about the oracle driver should speak up now or I will make a decision alone.

Why you are so concerned in making it differently than Metabase? Is it some kind of limitation of PEAR-DB API that prevents you to map Metabase behaviour? -- Regards, Manuel Lemos