-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Önnerby wrote: > So what you are saying is that opening a SQLite DB on a shared network > drive SHOULD work with multiple clients (if all servers and NFS-version > are updated to most recent version)?
Yes. However the locking implementations amongst other things need to be bug free. Since locking is so infrequently used on UNIX, the locking code is more likely to have bugs than other code. It gets even worse if the clients and servers are from different vendors. Dr Gerard Hammond wrote: > I hope the SQLIte db file doesn't suffer the same behaviour by assuming > a single network protocol-level locking mechanism. SQLite doesn't use network protocols. It uses the native file API provided by the underlying operating system. It is up to that operating system to implement the semantics that it provides in the various filesystem drivers. Martin Jenkins wrote: > Every time I see this NFS locking issue mentioned I wonder if there is a > tool which can determine whether the issue actually exists on a > particular system. The Unix locking API is bad enough as it is. Trying to find all possible bugs in NFS is even more difficult. You already have a tool - run production data with SQLite and if it gets corrupted then you have NFS problems. It is generally a bad idea to use SQLite databases over a network filesystem. Not only do the various locking implementations have issues, but performance is way worse. It is far better to use a networked database. You can get networked versions of SQLite. http://sqlrelay.sourceforge.net/ http://www.sqlite.org/cvstrac/wiki?p=ClientServer Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpntSmOOfHg372QQRAmzbAJ0eeYIx24+Y6USRVBfZB2KYYyqAngCfU/64 NBWpqu+85/bVCYeUR0ys+ck= =QbAt -----END PGP SIGNATURE----- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
