Thanks so much for the response. Can you suggest the specific pragmas - although I trust your insight that they may be more harmful than helpful - I would like to read more about them (if for nothing else to make sure I have not used them trying to fix this!).
Our current 'patch' for this was to build SQLite recovery in to our app. The user can go through a recovery step that actually dumps out all the changed/inserted records from their local copy of the db. Those changes are dumped as a SQL script and emailed to us. Although this is not ideal - this has been very helpful in recovering changes the user has made but have not been able to be synced. From that point, the user downloads a fresh copy of their database from our server (often 1-3+ GB). Thanks again for the feedback On Mon, May 4, 2015 at 10:21 AM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 4 May 2015, at 5:48pm, Brandon Frye <brandon at cogent3d.com> wrote: > > > I have assumed this is an iOS specific issue. This app has been in > > productions for 3 years now, with the lovely iOS 8.x release - we have > > started to see this problem. We have a couple thousand users, and it is > > only with iOS 8.x release that this problem has started to show itself. > We > > filed a bug with Apple, to which they answered 'This is a duplicate of > bug > > XXXXXXX'. And they will not allow us to view status, or progress, or > > ANYTHING to do with bug XXXXXXX (They are just so wonderful to work > with). > > Yeah, I've had that too. And it annoyed me too. You should eventually > get told when that bug gets fixed, but that doesn't help you now. > > > [snip] is there anything I can do on > > the SQLite side that would minimize chances of corruption? I read that > WAL > > mode is 'better' and have switched to that. But are there any other > things > > I can do to minimize chances of this? Would looking at the db file be > > helpful in any way? > > There are some PRAGMAs which will force more frequent writing of the > database but I suspect that rather than helping your situation they will > really only give the application more chances of crashing. > > Possibly ... just possibly ... keep a known-uncorrupted copy of the > database file as a backup. If your corruption can be detected easily from > the 'Malformed' report or by using "PRAGMA quick_check(1)" then dump the > new version of the database and work on a copy of the backup one. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- *LEGAL DISCLAIMER:* The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
