On 28 Aug 2014, at 4:57pm, Jan Slodicka <j...@resco.net> wrote: > Simon Slavin-3 wrote >> ...If the database is corrupted because your hardware flipped bits during >> power-loss and overwrote the wrong part of the disk, the corruption might >> well be in a different table... > > Clear. I just wonder that integrity_check first performs a number of checks > that validate that all tables are basically ok. As part of this process also > the indexes are formally declared as correct tables. Only then, when the > contents of the indexes is checked (thing that cannot be done for ordinary > tables), some problems are found.
I'm answering only some points here. If I don't comment on something assume I can't see why it might be causing your problem or anything wrong with what you're doing. It might be worth knowing that PRAGMA integrity_check is not perfect. It doesn't check every single little thing that might be wrong with the database file. It concentrates on making sure that if you wrote a program that read every row of every database, using any index for each table, you would get every row of data. It is good at checking that you could DUMP your data to SQL commands and read it back in again, but it's not a good exhaustive check that every byte of your database file is what it should be. That would take a lot longer to execute. > Killing can be done only by iOS. > > Suppose our app is running and the user switches to email reading. The app > continues running on background and roughly after 10 min the system sends a > notification that it is going to be frozen. iOS expects only the frontmost app to be using significant CPU or IO. It is normal in iOS applications not to do heavy work when your application is backgrounded unless doing so is a mainstay of your application, e.g. an email program checking for new mail. If possible, you should try to do your synchronisation when your app is frontmost only. However, I understand that this may not be appropriate for your app. > In reaction our app tries to interrupt the data communication with the > server (Problem1 - this may fail) Exactly. If your app is backgrounded when this happens you cannot give feedback to your user because your app is backgrounded. The interruption of communication with the server would normally come when your app is notified it's going to be backgrounded. This means that iOS will wait patiently for your app to cope with its problems before doing something intense like displaying a PDF. Similar problem: on an iPhone iOS will also kill your process if it tries to hog CPU or IO during a phone call. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
