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
