Hi Ryan, my problem is that I use the "most safest" mode that exists for SQLite and it still fails… Therefore, I need to know why it fails.
Regards, Hartwig > Am 2018-06-13 um 01:23 schrieb R Smith <ryansmit...@gmail.com>: > > > On 2018/06/13 12:21 AM, skywind mailing lists wrote: >> Hi, >> >> the original database is malformed. So, I cannot access it anymore besides >> doing a dump. > > There is currently no known way to read this since Inf and -Inf are not > recognized as floats but in stead look like identifiers. Perhaps this is a > useful enhancement to SQLite - but either way, right now your best bet is > indeed to search-replace the entire text file. > > As to your other question about why it is malformed - it simply means that > the schema doesn't match the data structure/layout/constraints anymore and > sqlite can't fix it and can't even know what all is wrong. Asking why > specifically is not useful. > > It's like when you see two random people on the street and ask "Are they > brother and sister?". If the answer is "No", there is no more that can be > said. It is not useful to ask "which one is not the brother?" or "why are > they not brother and sister?". > > It's a silly analogy, but it's hard to think of a better one now - The schema > and data are simply not happy together. In most cases this would be because a > Unique key (perhaps Primary) got written halfway when disk access died and > now has a situation where it has duplicate values in the Key. It might > however also be a root page index that falls outside the file, or indeed a > myriad of possible things - or worse - a combination of things so that if it > reported "Index has duplicates" and you manage to fix that (assuming you know > some magic), then you will find the next index is broken, and then page isn't > where it should be, and... and... and... - so there really is no point in in > saying what is wrong, just to know that the DB is broken to the point where > SQLite knows it is broken, but doesn't know if any of it is still o.k. or > what all is specifically broken. > > The corruptions may be vast and wide, but the reason is always singular - > There was a media write that failed to complete. That's all that needs to be > known, and to help prevent these things from happening, there is only one > good solution: choose more safe Journal modes. And yes, it may come at a > speed penalty. (On phones specifically you can also avoid DB updates when > battery is low, but that is not a fool-proof solution. A user can yank out a > battery, etc.) > > > I hope this helps to make sense of it somewhat, but I know none of it really > provides a solution, so apologies for that. > cheers, > Ryan > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
