> On 28 Aug 2014, at 12:23pm, Jan Slodicka <j...@resco.net> wrote: > > Simon Slavin-3 wrote >> When you exchange data, do you exchange data accessed as records (e.g. >> accessed using the SQLite API) or do you exchange files ? > > DB tables are being synchronized. The server sends xml data over http. This > data is parsed and converted into a collection of high level data records. > These records are then stored in the DB. At the same time some of the local > DB records are sent to the server.
Okay, thanks for that. It tells me several things not to worry about, and several things that won't matter at all. Most people who think they do sync do it by exchanging files and run into problems. Your solution seems to do it by exchanging data accessed using the SQLite API so you shouldn't have that sort of problem. > What is strange - the corruption may affect tables that were accessed > through different transactions. However, this may be explained by this > scenario: > - App is killed => synchronization is killed in the middle => DB gets first > corruption. > - App is restarted, DB corruption unnoticed I assume that you aren't using any PRAGMAs which speed up SQLite at the expense of safety, for instance, keeping journals in memory or turning off synchrony. If you're letting SQLite handle journalling properly then DB corruption caused by crashes should always be noticed and rectified, with the database restored to the most recent transaction boundary. Any failure to do that properly is a fault in SQLite and the dev team will fix it. > and the user starts > synchronization again. Synchronization resumes with the table where it > stopped the last time. (I would expect that the DB corruption is discovered > now, but it does not happen for some reason.) Synchronization updates a few > tables, when the app is killed again causing another DB corruption etc. It would be nice to think that corruption which happens while writing to a particular table would corrupt only that table. Unfortunately, that's not the case. You may have an app which writes to only one table in the database, and then suffer power-loss. 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. Or a different file ! I am slightly concerned about your mention of "App is killed". Is this part of your routine operations or are you just being careful to mention that it's possible ? If your app runs on an iPhone it should always get notification before it is put into the background or terminated, even in low-battery conditions. You should respond to those notifications appropriately. Normal practise these days is to close database connections when your app is backgrounded and reopen them when they are needed again, unless your app has functionality which needs to continue when it's in the background. And you need to call _close() when your gets termination notification, of course. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
