> techi eth wrote: >> 1. "Any database clients wishing to write to the database file while a >> backup is being created must wait until the shared lock is >> relinquished." > > Example 1: Loading and Saving In-Memory Databases will not fulfill > this shortcoming.
In-memory databases cannot be accessed by other clients. > Example 2: Fulfill the shortcoming but cost of more time due to > restart of backup from fresh in the case of INSERT, ALTER, DROP & > UPDATE. > > Addinitionally what happen if other process is not able to complete > operation within timeout duration? If you tell the backup API to copy all pages at once, you get a behaviour similar to a plain file copy. Using smaller steps allows you to balance the speed of the backup itself against the risk of other clients being locked out for too long. >> 2. "It cannot be used to copy data to or from in-memory databases." > > I haven't got it full but I understand by CP I am able to copy any > file in Linux system. And an in-memory database does not have a file. >> 3."If a power failure or operating system failure occurs while copying >> the database file the backup database may be corrupted following >> system recovery" > > This is very useful benefit. What is the resulted outcome of power > failure or OS failure if we use backup API? The transaction is rolled back, and the destination is not changed. Regards, Clemens _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
