> On Sep 24, 2019, at 2:14 PM, Randall Smith <rsm...@qti.qualcomm.com> wrote: > > My question is: Do the commit-or-rollback semantics of SQLite transactions > work if the connection to the file system is weird?
What filesystem is it — SMB, NFS, AFP, …? I'm not an expert, but in general I think the database file should be OK if the connection is dropped, as long as the filesystem has some kind of 'fsync' equivalent. The bigger problem is file locking: > file locking logic is buggy in many network filesystem implementations (on > both Unix and Windows). If file locking does not work correctly, two or more > clients might try to modify the same part of the same database at the same > time, resulting in corruption. Because this problem results from bugs in the > underlying filesystem implementation, there is nothing SQLite can do to > prevent it. > > A good rule of thumb is to avoid using SQLite in situations where the same > database will be accessed directly (without an intervening application > server) and simultaneously from many computers over a network. (from https://www.sqlite.org/whentouse.html <https://www.sqlite.org/whentouse.html> ) From what I've heard, this is especially problematic with NFS. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users