Quote:
Originally Posted by PeterT
I've taken a look, and the problem is that the content table has some corruption. A count of the rows in it shows 15117, however I'm only able to retrieve 4,757 rows from it  so attempts to build a new database from a dump of the old one fail.
An integrity check shows
Code:
*** in database main ***
Page 17620: btreeInitPage() returns error code 11
On tree page 16705 cell 80: Child page depth differs
On tree page 16705 cell 81: Child page depth differs
Page 17650: btreeInitPage() returns error code 11
On tree page 16705 cell 92: Child page depth differs
On tree page 16705 cell 93: Child page depth differs
On tree page 6819 cell 20: 2nd reference to page 7209
On tree page 6819 cell 20: Child page depth differs
On tree page 20 cell 1: Child page depth differs
Page 17619 is never used
Page 17621 is never used
Page 17648 is never used
Page 17649 is never used
rowid 19971 missing from index analytics_events_timestamp
rowid 19971 missing from index sqlite_autoindex_AnalyticsEvents_1
wrong # of entries in index analytics_events_timestamp
wrong # of entries in index sqlite_autoindex_AnalyticsEvents_1
If davidfor sees this, any thoughts?
I know you don't want to reset the database but you probably will have to sooner or later.
|
I don't think it can be recovered. From what I have seen, the following errors can be fixed:
- "Page x is never used" - Fixed by compressing the database. In SQLite, this is the VACUUM command.
- "rowid x missing from index y" - Fixed by rebuilding the index or a compressing the database
- "wrong # of entries in index" - Should be fixed by rebuilding the index or a compressing the database.
I am pretty sure there is no way to recover from the tree errors. That means an internal data structure has been broken and no longer points to valid data. It could be restricted to one table or it could be all the tables. A compress might fix the error but it will almost definitely mean data loss. From where the error is, the "content" table is corrupt. I don't think a recovery of that will leave the database in a consistent state. And I'm pretty sure that if Paola powers off and on, some books are going to be lost or at least the status will be. And it wouldn't surprise me if the device decided the database was to bad and created a new one and prompted for login.
At this point, the best thing would be to dump the Bookmark table, or at least the rows for the sideloaded books (VolumeID LIKE 'file://mnt%' should get them), do the signout and in and then reload the Bookmark rows. I would do this sooner rather than later.