You may get it to work, but using an sqlite database file on a network file system has been reported to be troublesome. Here is a quote from <http://www.sqlite.org/lockingv3.html> in a section entitled "How To Corrupt Your Database Files":

--------
SQLite uses POSIX advisory locks to implement locking on Unix. On windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under windows. Your best defense is to not use SQLite for files on a network filesystem.
--------


Reliable locking is necessary for sqlite to succeed in allowing more than one process to access the database contents without corruption.

There is more discussion of this in the mailing list archives and in the sqlite source files.

--Steve

On Jan 31, 2005, at 4:44 PM, Richard Boyd wrote:

Hi,

I’m writing a database that will be accessed remotely over Ethernet. I had started to write a protocol that would float on top of TCP/IP but after reading some posts here it seems that it would be overkill. Is it practical to access the database file remotely and run commands on it from the remote PC? Are there going to be problems with sharing conflicts with more than one application accessing the database simultaneously? I know from reading some Sqlite documentation that there is some protection built into Sqlite. Does it work automatically or is there something I’d have to do at the operating system level?

FYI: I’m using Linux for the computer where the database is stored and windows for the machine that will remotely access the database over Ethernet.

Thanks again,

Richard.
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005

Reply via email to