On 4 Mar 2015, at 9:07pm, Scott Hess <shess at google.com> wrote: > In the time I've been involved with high-volume SQLite clients (Google > Gears, then Chrome), what I've found is that the corruption invariably > (*) ends up being a case where distinct pages were not written > atomically, but where each page in isolation is completely valid when > you inspect the data. For instance, you update a row and the > corresponding page for the table btree is updated but the page for the > index btree is not. Usually this correlated with power-failure > events, but since corruptions of that sort aren't detected until > SQLite actually compares the pages, the cause and detect can be > separated by months.
Does SQLite automatically detect and uncorrupt these problems the next time it opens the database, or has something been done to the hardware to break in-order writing ? Simon.
