> The only reason mysql_num_rows() returns the number of rows from a
> SELECT statement is because MySQL immediately returns ALL of the rows
[quoted text clipped - 17 lines]
> ahead and issue your first db2_fetch_*() call -- if it returns FALSE,
> then you know that there are no rows in the result set.
I have written a general sql executor function which tests odbc_num_rows
for the conditions exactly 0, exactly 1, exactly 0 or 1, at least 1
returned result and fails/succeeds on the comparison. How do I do all of
these without impacting later fetches, especially if I'm trying to use
other advice I've gotten here: do not pass the row number to
odbc_fetch_array and use odbc_fetch_array for a loop predicate?
> 3. Use a scrollable cursor for your SELECT statement -- this uses more
> resources on the database server but will allow db2_num_rows() to
[quoted text clipped - 4 lines]
> db2_execute($stmt);
> $num_rows = db2_num_rows($stmt);
Would a scrollable cursor be required if I wanted rows 125-149 of the
result? I make use of odbc_num_rows for driving such fetch operations as
well.
> Oh yeah, and please stay away from Unified ODBC for all of the reasons
> mentioned in my article (the --with-ibm-db2 compile option) and use the
A reference to the article would be appreciated.
> ibm_db2 extension instead (http://php.net/ibm_db2 or install the free
Is either of these 1-1 substitutable with the corresponding odbc
library, by simply changing the odbc_* names to db2_* names?
> Zend Core for IBM from http://zend.com/core/ibm/ for precompiled PHP +
> ibm_db2 extension). You'll have much more functionality and better
> performance.
Knut Stolze - 30 Nov 2005 21:51 GMT
> I have written a general sql executor function which tests odbc_num_rows
> for the conditions exactly 0, exactly 1, exactly 0 or 1, at least 1
> returned result and fails/succeeds on the comparison. How do I do all of
> these without impacting later fetches,
The you would need scrollable cursors to be able to scroll back after the
fetch in your counting function.
> especially if I'm trying to use
> other advice I've gotten here: do not pass the row number to
> odbc_fetch_array and use odbc_fetch_array for a loop predicate?
I didn't say to avoid it at all costs. I just meant that you get often a
better performance if you stick to forward-only cursors.
>> Oh yeah, and please stay away from Unified ODBC for all of the reasons
>> mentioned in my article (the --with-ibm-db2 compile option) and use the
I'll second that. Especially if you try to use LOBs, you're in a lot of
trouble because the unified ODBC code screws up quite badly - no proper
error handling and a few other issues that Dan does not explain in his
article.
> A reference to the article would be appreciated.
http://www-128.ibm.com/developerworks/db2/library/techarticle/scott/0614_scott.html

Signature
Knut Stolze
DB2 Information Integration Development
IBM Germany