> Hint: How does the SQLite connection you are currently using know that no > other SQLite connection won't be updating the database?
Isn't it a SHARED lock that will ensure that no other connection is updating the database? And isn't SHARED lock should allow another SHARED lock? I believe the problem here can be either in buggy file locking via NFS or in journal file left in file system in case of journal_mode = TRUNCATE or PERSIST. I don't see other scenarios that could cause this. Pavel On Sat, Oct 24, 2009 at 8:55 PM, Roger Binns <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jamie wrote: >> Given all this, why am I on rare occasions getting a SQLITE_BUSY >> return code when calling sqlite3_prepare_v2() or sqlite3_step() ? > > Hint: How does the SQLite connection you are currently using know that no > other SQLite connection won't be updating the database? > > If you want to prevent any locking then first read: > > http://www.sqlite.org/compile.html#enable_locking_style > > When opening your database also specify the vfs as "unix-none" and that will > do what you want. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrjohUACgkQmOOfHg372QTqZgCffFozPdr0BV57IJc6ijJDIpNu > XsAAn0qbOVwQfIB6Sv2uCX9SJUPpYkeD > =18qu > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
