On 27 Dec 2017, at 6:55pm, Simon Slavin <slav...@bigfraud.org> wrote:
> An alternative might be to run "integrity_check" on backup copies which don’t > show up anything on "quick_check". This could be done without blocking the > production system. If you never find anything then you know "quick_check" is > all you need. But it might spot corruption in some databases you don’t think > have been corrupted yet. Just to be clear, SQLite database files can be corrupted in ways that don’t show up until a particular row of a particular index is used. If a row pointer of a particular index becomes corrupt, and something tries to UPDATE that row, SQLite will corrupt the file even more, causing corruption to spread to the table, and to other indexes of that table. This is why using a database without problems for months, then suddenly having a problem, does not mean that the database only just became corrupt. The only way to check everything (at least, the developers hope it’s everything) is "PRAGMA integrity_check". Note: the above is simplified for the sake of simplicity. SQLite does a certain amount of internal checking. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
