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

Reply via email to