Edward Wilson wrote:
What I was trying to say was: with other db products the drivers (or something somewhere) calculated the number of rows returned in a query automagicly. I have never had to do anything 'extra' to get the number of rows in a query other than resultset-object.rowcout - 'rowcout' being whatever the syntax was for that particular environment. So what I meant was, I have always taken for granted that the rowcount was 'apart of' the query returned from the database and not something that I had to do 'extra' in addition to fetching the data to begin with. I hope this was clear.
I think you'll find that any interface involving a "resultset object" is really a wrapper that talks to the database at a fairly low level and actually retrieves all the selected rows into its internal memory, later parcelling them out in response to method calls. Of course it can count the rows as it retrieves them and make the count available through a method or variable. SQLite's native API actually corresponds to the low-level communication between the wrapper and database; the row counting would be done by the code that calls the API. I believe that a while back drh strongly implied that most substantial code should be accessing SQLite via a wrapper rather than the "raw" API.
