On 21 Mar 2014 at 01:06, Simon Slavin <slav...@bigfraud.org> wrote: > On 20 Mar 2014, at 11:33pm, Richard Hipp <d...@sqlite.org> wrote: > >> On Thu, Mar 20, 2014 at 7:18 PM, Tim Streater <t...@clothears.org.uk> wrote: >> >>> I had a case where attempts to access a table in a user's db gave "no such >>> table", where 60 mins previously (according to the log) querying that table >>> gave no problems. About a day and a half later the user's machine had what >>> he described as a "bad crash", so I'm suspecting he has a failing disk. >>> [snip] >> >> PRAGMA integrity_check catches most things. PRAGMA quick_check also does a >> good job, and it is much faster. The only difference is that quick_check >> does not verify that indices agree with tables, whereas a full >> integrity_check does. > > All useful as far as SQLite itself goes, and better than nothing. > Unfortunately, failing hard disks do weird things in weird orders. And the > interaction between the physical hard disk and the on-board cache makes it > impossible to find out what's really on the disk. There's only one way to > check whether the whole file is readable from a disk: read the whole file from > the disk. Then do an integrity check on the copy you just made. > > Practically speaking, it's impossible. Concentrate on having really good > backups instead.
Well quite. But although the question of backups is a matter for the user, as the software is on his machine, I'll probably beef up the startup checks and add periodic checks of each db (the app does some periodic checks anyway). I'm hoping the user will forward me his damaged db so I can use it for testing. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
