thank you for the hint, my current approach to copy the database file, is even more restrictive -- it is encapsulated by an EXCLUSIVE transaction. ;)
In my case it is unlikely that it will block anybody from using the server since it is a typical "working-hours" application and the backup will usually take place around midnight. kind regards Marcus Nuno Lucas wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
