On Wed, May 27, 2009 at 12:51 PM, Marcus Grimm <mgr...@medcom-online.de> wrote: > Yes, I understood that this is unsafe and I'll not use it right now. > But my feeling is that it will be an option for the future. My databases > are not so big (say in megabyte range) and currently my server application > will do a backup every day (more or less a simple file copy). So even if > I'll see a corrupt database the customer will loose only one day work, > as maximum. This should be tolerated since I estimate the liklyhood > of such an event extremely low (powerfailure or OS crash at exactly the > "wrong" time), powerfailure by the way can be workaround by using a > battery pack which is common on server hardware, I guess.
Ok, but note that backing up sqlite database files could get a corrupted database on restore if you don't backup the sqlite database file AND the journal file as an atomic operation. A work around for this situation is to start an immediate transaction [1] (which will assure no other writes are pending, although allowing reads to proceed), backup the database (copy the file) and only then end the transaction (a simple "BEGIN IMMEDIATE" --> "END" operation). Regards, ~Nuno Lucas [1] http://www.sqlite.org/lang_transaction.html _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
