On 2013/06/23 00:15, Simon Slavin wrote:
//...
UPDATE myTable SET C1 = [calculation] WHERE rowid > [lastupdatedrowid]
then update the updateprogress table. Since there is no searching needed,
there’s no need for scanning the table, and no need for any indexes.
Simon.
One caution on this approach - I once made a logger which logged to SQLite, several devices logging once a second, so quite a
well-paced consumption of rowids.
Another app/thread came in and archived anything older than 6 months by reading, compressing, deleting (to keep querying to
acceptable speeds).
Another thread still validated/updated logged readings - this one used this scheme
of 'WHERE rowid > '+lastCheckedRowID;
It all worked perfectly but then went horribly wrong at some point after rowids consumed all of 32 bits (I think), the next rowids
were not even starting at the beginning again (where stuff were deleted first), it seemed almost random at times... Brought a whole
system to its knees. (No catastrophic failures, just locking up in forever-running queries etc). I just changed how the system
worked at the time, did not have time to research the problem more, so no great advice on what to do if it happens.
Not sure if this is still the behaviour with newest version of SQLite - maybe
someone can confirm.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
