Rich Rattanni uttered:
The databases will be in flux, and I didnt necessairly want to suspend
the application that is performs reads and writes into the database.
A simple copy worries me because it seems like messing with SQLITE on
the file level is dangerous since you circumvent all the protection
mechanisms that provide fault tolerance. I didnt want to have to
worry about if the database has a journal file that needs copied, or
any other situation like that. I figured using the SQLITE API to do
the copy would award me some protection against corruption.
You're right to be cautious. Never copy an in use database if that
database could possibly be updated.
If you open the database, and obtain a SQLite read lock on it, you can be
sure it is not going to be modified, and can be safely copied at the OS
level.
Best way of doing this is to execute a 'BEGIN IMMEDIATE', copying the
database file, then executing a 'ROLLBACK' to end the transaction.
To limit the time the database is locked, I suggest copying the file to a
local filesystem first, then transferring across the network after the
lock is released.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
