On 24 Mar 2014 at 08:36, Dominique Devienne <ddevie...@gmail.com> wrote:
> On Mon, Mar 24, 2014 at 6:23 AM, Roger Binns <rog...@rogerbinns.com> wrote: >> So you don't have to use it. Those of us who would rather proactively >> know about data corruption (to the best of SQLite's ability to detect it) >> are happy to take whatever hit there would be. After all, fast queries on >> corrupted data are pointless. > > +1 > >> And as we see in messages on this list, finally spotting corruption long >> after it first happened is very hard to recover from and hard to nail down >> the cause for. > > Indeed. Fail-fast on corruptions trumps speed for many use cases. --DD I eventually found out what happened in my case. The user sent me the "corrupted" file, and on testing it I found it wasn't corrupted at all, just completely empty. In fact I was able to make a bit-for-bit duplicate of the file he sent by doing this: Second-Mini% php -a Interactive shell php > $dbh = new sqlite3 ('wiggy'); php > $dbh->exec ('vacuum'); php > My app does some periodic housekeeping, which includes occasional vacuuming of some files. From the logs, I deduce that the OS completely lost this file [1], which got recreated at the next housekeeping and then vacuumed, thus producing an uncorrupt but useless file, as of course it didn't have any tables. I'm considering changing the app to use one or other of the flags SQLITE_OPEN_READWRITE and SQLITE_OPEN_CREATE for when I expect the file to be there or not, so the app gets immediate notification. [1] The user's OS crashed "badly" (his term) the next day. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users