> Am I missing something here or if I want to prevent this, is my only option > to modify our build of SQLite to open the file for exclusive access?
Yes, opening with exclusive access is the only option for you. But with latest SQLite version you don't have to modify SQLite sources for that. You can use xSetSystemCall in sqlite3_vfs to change open() call and add exclusiveness flag in provided function (see http://www.sqlite.org/c3ref/vfs.html). Pavel On Fri, Jul 29, 2011 at 2:49 AM, Jonathan Little <jlit...@ata-sd.com> wrote: > I've been tearing my hair out over this for a little while, but I feel like > there must be something simple I'm missing. Based on the behavior I'm seeing, > the EXCLUSIVE locking mode isn't working the way I'd expect it to work based > on the docs at http://www.sqlite.org/pragma.html#pragma_locking_mode. > > Specifically, that page says that locking_mode = EXCLUSIVE is useful if "The > application wants to prevent other processes from accessing the database > file." However, if I start up a SQLite shell, set the locking_mode to > exclusive, and perform an insert or other write operation (such that the > exclusive lock should be acquired and not released), I can still read the > file from other processes (e.g. I can copy it using a file manager UI). I > cannot open it in another instance of SQLite (as expected) but from the > documentation I'd expect not to be able to read it from another process at > all until the lock had been released somehow or the database closed. > > I originally thought it was an OS issue but the behavior is the same on > Windows Vista w/ SQLite 3.7.7.1 and Mac OS X 10.6 w/ SQLite 3.6.12. > > This behavior seems undesirable to me -- we've got users of our application > copying the database file using Windows Explorer while it's being written to, > and ending up with inconsistent/corrupt databases. Am I missing something > here or if I want to prevent this, is my only option to modify our build of > SQLite to open the file for exclusive access? > > Jonathan LittleInformation (including any attachments) contained in this > electronic transmission is a PRIVILEGED AND CONFIDENTIAL COMMUNICATION. It > is for the sole use of the sender and the entity named above. If you > received this electronic transmission in error, you are required to > immediately delete it in its entirety without making a copy. Further > dissemination is absolutely prohibited. Thank you. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
