On 10 Apr 2014, at 5:04pm, Grzegorz Sikorski <g.sikor...@kelvatek.com> wrote:
> The problem is we occasionally observe database corruption and whole database > becomes rubbish. The problem is very rare and occurs only (as far as we were > able to confirm so far) if there is a power lose during write to the database. After power is lost, presumably you then reboot the device and restart the app. Does your rebooting procedure, or anything else done before the database is reopened, mess with the database or journal file in any way ? Especially, does it rename, move or delete the journal file ? Does you app use any PRAGMAs when it opens the database file (apart from you having put it in WAL mode once upon a time) ? When the database is corrupted, I assume that the file length remains the same (or at least is plausible for an uncorrupted database) but that some of the file is overwritten with bytes which shouldn't be there. Do these bytes look like data which could be from elsewhere in the database file, or elsewhere on the storage medium, or something which might have been in memory, or complete gibberish ? If you can't answer some of the above, don't worry. It might help, might not. > We admit there may be a problem with SD drivers, POSIX mutex implementation > or ext4 driver (we are running relatively old version of Linux kernel), > however we have never observed corruption of any other file on the same > partition, even though this partition is heavily used for other purposes > (syslog, all temporary data, configuration, some exported data files in zip > format). We also use POSIX mutexes in other programs and have never > discovered any issue (apart from invalid use in developer's code;) Does > anyone know if there is any "unstable/unknown" part of SQLite3 code which may > cause this issue? Thank you for the details which has saved a lot of laborious back-and-forth. I'm not aware of any issues involving corruption as you describe, though someone else who reads this list may be. Or may be able to solve your problem another way. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
