On 05/27/2015 11:59 PM, Wade, William wrote: >> 3) The writing thread prefers to delete any existing file. If it can't do >> that (some readers currently have the file open) it gains an exclusive >> read/write lock (consistent with no reader has a transaction in progress) >> and truncates the file to zero length, writes its new header (including his >> own uuid, indicating that this is logically a new file). When existing >> readers get around to reading again, they will check that uuid, and handle >> the change in writers "gracefully." >> > >But instead of using a regular SQL transaction to drop all the old >tables, use the backup API to clobber the existing database with the new >one. > > https://www.sqlite.org/c3ref/backup_finish.html > >Using the backup API, the clobber operation is still done as a regular >SQLite transaction - so all the locking and notifying of other clients >gets done right. The amount of IO (and CPU) required should depend on >the size of the new db only, not the existing db size. And it won't >matter if the existing db is corrupt or not - as the backup API never >actually examines the contents of the existing database. > >Dan
Interesting idea. Could this also a solution to my problem described in the thread "emptying tables"? Rene Kernkraftwerk Goesgen-Daeniken AG CH-4658 Daeniken, Switzerland Diese Nachricht (inkl. Anhaenge) beinhaltet moeglicherweise vertrauliche oder gesetzlich geschuetzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrtuemlicherweise erreicht hat, sind Sie hoeflich gebeten, diese unter Ausschluss jeder Reproduktion zu vernichten und den Absender umgehend zu benachrichtigen. Besten Dank.
