On Tue, 12 Mar 2019 10:36:37 -0400 [email protected] wrote: > The problem is basically that as part of a test, the customer wants > to power fail the device, and then to be able to recover (after the > device restarts) data that was generated/stored as close to the power > failure as possible. ... > Unfortunately, when doing this, it appears that significant amounts > of data that should be in the database are missing and/or corrupted, > and this doesn?t appear particularly dependent on when the failure > occurs.
Only 3 possibilities exist: 1. SQLite finished its transaction before the power cut, and the data were committed and do appear in the database later. 2. SQLite did not finish its transaction, and the transaction was rolled back as part of database initialization after power was restored. 3. The hardware or driver reported the data were written when they were not. We can dismiss as statistically insignificant possibility #4, a bug in SQLite, because of SQLite's excellent testing regimen and gigantic user base. If you can confirm that SQLite finished the transaction whose data the database does not reflect on restart, you really must suspect the driver or device. I don't know much about USB drives, but consumer grade hard drives *normally* lie about committed data for performance reasons. "It's easy to make it fast if it doesn't have to be right." USB devices face at least as much temptation to misrepresent their performance. --jkl _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
