Igor puts it very clearly. No DBMS knows how many rows are in a
selection until the selection has been performed. Therefore you cannot
do a progress bar since the selection is complete before you have the
necessary information to build the bar. The answer is to use some other
form of progress indicator, such as a running count, a running man or
even a running Duke etc. Performing two SELECTs is rather pointless
unless the progress bar is meant to present the progress of post-SELECT
processing which is very much slower than the actual SELECT.
One of the nice feature of Sqlite is it's callback and step functions so
that it is not necessary to store any results, permitting the building
of robust programs which cannot hit local storage limits and fail.
JS
Igor Tandetnik wrote:
Edward Wilson <web2ed-/[EMAIL PROTECTED]> wrote:
This is really an important feature to have, I am surprised it's not
already there. I too have had the same question but have just never
asked.
Well, if the golden standard is mysql_num_rows, consider the following
bit in the documentation:
<quote>
The use of mysql_num_rows() depends on whether you use
mysql_store_result() or mysql_use_result() to return the result set. If
you use mysql_store_result(), mysql_num_rows() may be called
immediately. If you use mysql_use_result(), mysql_num_rows() does not
return the correct value until all the rows in the result set have been
retrieved.
</quote>
mysql_store_result is essentially equivalent to sqlite3_get_table - it
does not return until all rows are retrieved and stored in memory. Note
that sqlite3_get_table does return the number of rows. Of course it is
pretty useless for the purpose of providing progress indication.
mysql_use_result is equivalent to calling sqlite3_step in a loop - and
just as in SQLite, MySQL cannot return the row count until all rows are
fetched. Well, SQLite does not provide the row count in this case
either, but you can easily maintain your own counter. Again, this does
not help much with progress indicator.
The idea of issuing two selects is, well, a hack, and knowing how
many records one has in a result-set is a powerful feature.
The fundamental problem is that, for many queries, counting all rows is
actually as complex a task as retrieving them in the first place. This
is a property of SQL language and relational data model in general, it's
not specific to SQLite or any other engine. There is no way around it.
Igor Tandetnik
