I tried Greg's suggestion of: "If you have an index on the primary key and count that then it will run as quickly as possible." But unfortunately this still wasn't fast enough for my situation. I implemented the scheme Dan describes below and it works well. The overhead for insert is not as important for my application. Thanks for all the help. Buzz
"Kennedy, Dan" <[EMAIL PROTECTED]> wrote: > Doesn't sqlite "know" the number of rows in each table without > explicitly counting them? Thanks for any help Buzz No it doesn't know that. One thing you could try using is triggers. eg. Set a trigger to increment a value in some other table when a row is inserted, and decrement the value when a row is deleted. Then instead of your SELECT count(*)... statement you can just pull a single row from the database. Probably only have to read one page, as opposed to reading every page in the table. Naturally, you'll pay a price for this. Basically you will be reading and writing an extra database page every time you do an insert or a delete. This might be about 50-100% overhead on each insert/delete. Dan. --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing
