On 8 May 2019, at 3:42pm, Andrew Moss <curioussq...@googlemail.com> wrote:
> My question is, if we limit the application (through other means) to a > single writer, but allow multiple readers, does that remove the risk of > database corruption from multiple SQLite processes? > > Any notes from other users who had to do something similar in the past? If you're going to do it, that's the way to do it. I can't say having only a single writing connection will reduce corruption, because you might not get corruption either way, but it might do, and it'll simplify diagnostics if anything bad does happen. I endorse José's note on timeout. In fact I'd use an even longer timeout, perhaps 30 seconds. After all, what are you going to do if you crash with a 'database busy' error ? A reminder that this timeout must be set by all connections to the database, not only the ones which can write to it. I also believe that with the setup you describe setting the journal mode of the database to WAL will lead to the best behaviour, though I have no reasoning or stats to back that up with. Also, watch what else that server is doing. Is it also a print server ? Does it manage a RAID array in software ? Those two things can hog CPU, delaying shared filespace replies. Lastly, keep more than one generation of backups, and if you have or can set up a three- or six-monthly maintenance procedure which includes PRAGMA integrity_check, that would be good. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
