Thanks for answer. Let me put my query on point mentioned by comparing historic way of doing copy at the start of link. 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. 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.I understand SELECT will not add time. Addinitionally what happen if other process is not able to complete operation within timeout duration? 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. 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? On 7/31/13, Simon Slavin <slav...@bigfraud.org> wrote: > > On 31 Jul 2013, at 12:56pm, techi eth <techi...@gmail.com> wrote: > >> I have followed below link for details. It say “If another thread or >> process writes to the source database while this function is sleeping, >> then >> SQLite detects this and usually restarts the backup process when >> sqlite3_backup_step() is next called”. >> >> - It means it will start back-up from start or resume from last left page >> but making sure all update will be written in backup file. > > Every time a change is made the backup has to restart from the beginning > again. So if, for example, it would take 300 seconds to backup the entire > file, the backup process will not complete until there has been a 300 second > period when no changes were made to the file. > >> - Is their any issue if process acquiring database handle will do both >> the >> operation (Writing & Backup). > > No. This is not a problem. Though, of course, if anything does use that > handle to write to the database the backup will be (automatically) > restarted. > >> http://www.sqlite.org/backup.html > > Simon. > _______________________________________________ > 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
