> boun...@sqlite.org] On Behalf Of Simon Slavin > Sent: 16 October 2011 21:53 > > Perhaps he could read the rows LIMIT 100 into a buffer (after all, he's going > to need them eventually for when he displays them), then count how many > rows he got.
Yeah, I would go that way also. But it sounds a bit like Fabian both wants to have the total number of records available and at the same time limit the count. It is just not possible to do both at the same time as far as I can see. Thus, you are left with following options as far as I can see: 1. As Slavin mentions: Read a certain number of records, e.g. 101 and change your code so that the user can ask for e.g. 100 additional records at a time. Possibly you could have an extra function that the user could activate to have a total count if he so wishes. This would then read all records and you would not have to worry about performance as all records (unless there are very many) will be in the memory cache and subsequent request for these records should be fast. 2. If there are many concurrent users and the query requests from these are quite predictable, e.g. straight reads of all records in certain tables, you could perhaps have a local background job regularly count the number of records for the relevant tables/queries and store these count results in a special status table. Your client program could then read the number of records from the special status table as well as the first 101 records from the actual data carrying table. The user could then get the first 100 records, and continue with batches of 100 as needed. If these options does not seem to fit, I think that you have to explain a bit more about how your solution is, what you expect and how you access the database. /Frank _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
