Ok - it looks like the network file system is the main problem. That is what introduces the risk of database corruption, and 'quickly' too! SQLite apparently locks perfectly well and maintains integrity through concurrent access but the network file system is likely to break.
It definitely now looks like SQLite is *not* the tool for this job. Thanks Richard, I think that has cleared up my question completely. Thanks to everyone who posted. I appreciate your help. Anil. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 2 February 2007 1:34 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Appropriate uses for SQLite "Anil Gulati -X \(agulati - Michael Page at Cisco\)" <[EMAIL PROTECTED]> wrote: > > I am trying to decide whether I can use SQLite for a website that runs > on 4 load-balanced servers using networked file storage mounted by all > servers for common data access. This sounds like a job for a client/server database. You can probably make SQLite work for this, but it is not really what it was designed to do. Use the right tool for the job. Do not hammer a nail with a screwdriver. > > The issue is that there may be short periods where multiple users will > be updating around the same time and I want to make sure that the > possibility of corruption is extremely low. I am asking for more > detailed information on the above issues to clarify my decision. > SQLite won't corrupt, even with simultaneous access, as long as your network filesystem is working correctly. The problem is, not many network filesystems work correctly. Bugs in the network filesystem will quickly lead to database corruption. Nothing SQLite can do about that. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
