On 15 October 2012 12:32, Keith Medcalf <kmedc...@dessus.com> wrote: > > Define "clients". Do you mean multiple client processes running on a single > computer against a database hosted on an attached local device, such as on a > Terminal Server for example? Or do you mean multiple clients connecting over > LANMAN/CIFS/NFS to a database file sitting on a remote fileserver?
It's the second one. The database file is being accessed over the network. > If file locking is working correctly, you cannot have multiple writes to a > database. Write operations to the database are exclusive. As Simon correctly guessed, the database isn't actually being corrupted; I'm just getting an error that suggests that it is. So I suspect the writes are not conflicting, but one is failing (possibly) due to another happening at the same time and whatever locking/waiting not being observed properly results in this 'malformed' error rather than a blocking error. > You may wish to try forcing locks to be acquired sooner when updating the > database by using BEGIN IMMEDIATE or perhaps even BEGIN EXCLUSIVE before > updating the database, and COMMIT when you are done. You will then also need > a busy-timeout so that other readers/writers will wait for that operation to > complete. You can set the timeout when creating the connection with sqlite3 > in python, or by using PRAGMA busy_timeout Thanks - I'll give that a shot. > Latency of locking operations over network connections can play havoc, > however. It is possible if you are using a network mounted database file > that the write operations are not being flushed properly and or the locks are > not propagating in a timely fashion. > > http://www.sqlite.org/lang_transaction.html > http://www.sqlite.org/lockingv3.html Reading up now... Cheers, Larry _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users