On 11 Apr 2014, at 11:49am, Grzegorz Sikorski <g.sikor...@kelvatek.com> wrote:
> No, the journal files (-wal/-shm) are not modified at all. The only think > that may be done (but rarely) is changing its privileges to rw-rw-r--. We > need to be able to open database in read-only mode by group and as far as I > know there is no other way to change privileges in SQLite3. I'm trying to remember whether this works the way you'd expect it to. I don't remember how SQLite reacts to having read-only access to a journal file for a database in WAL mode. I hope an expert will post saying whether this works the way one might expect. Apart from that, that's the only thing in your answer that suggests a problem. The rest of what you're doing should be okay. The most important thing you wrote Dr Hipp already commented on: the fact that you occasionally have to do 'fsck -p' suggests that your corruption is at the storage-device level and not caused by anything in SQLite. On 11 Apr 2014, at 12:22pm, Richard Hipp <d...@sqlite.org> wrote: > (1) Using WAL mode is good. But the usage pattern makes a difference > too. Please make sure you have at least one process that opens the > database (in WAL mode) and keeps it open all the time. That processes > doesn't have to do anything with the database other than hold it open. > SQLite deletes the WAL file when the last connection closes. By having one > process hold the database open, that prevents the WAL file from being > deleted, which reduces the risk of corruption. I seem to recall that the sqlite3_open() call dos not really open the database. The open actually happens when the data is first accessed. So to do the above "one process that opens the database" does one need to do some kind of access (presumably a harmless SELECT) ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
