> Le 15 févr. 2017 à 18:44, Clemens Ladisch a écrit :
>
> Olivier Mascia wrote:
>> A good approach ... is to drive the backup by a single call to
>> sqlite3_backup_step()
>
> This is indeed what you should do with WAL.
>
>> The only downside is that I loose the capability
Olivier Mascia wrote:
> A good approach ... is to drive the backup by a single call to
> sqlite3_backup_step()
This is indeed what you should do with WAL.
> The only downside is that I loose the capability to monitor (or inform users
> if needed) of the backup progress.
That was never the
> Le 15 févr. 2017 à 17:41, Olivier Mascia a écrit :
>
>> Le 15 févr. 2017 à 16:04, Olivier Mascia a écrit :
>>
>> Dear all,
>>
>> https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it
>> clear that connections (other than the one used
> Le 15 févr. 2017 à 16:04, Olivier Mascia a écrit :
>
> Dear all,
>
> https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it
> clear that connections (other than the one used for the backup feature) which
> writes in between calls to
Dear all,
https://www.sqlite.org/c3ref/backup_finish.html#sqlite3backupstep makes it
clear that connections (other than the one used for the backup feature) which
writes in between calls to sqlite3_backup_step() will force the next
sqlite3_backup_step() to start again the whole copy
5 matches
Mail list logo