Handling failed downloads

Using blocking download acknowledgement

Blocking download acknowledgement has been deprecated. Use non-blocking download acknowledgement whenever possible.

Bookkeeping information about what is downloaded must be maintained in the download transaction. This information is updated atomically with the download being applied to the remote database.

If a failure occurs before the entire download is applied to the remote database, and if you change SendDownloadAck to ON, then the MobiLink server does not get confirmation for the download and rolls back the download transaction. Since the bookkeeping information is part of the download transaction, it is also rolled back. Next time the download is built, it uses the original bookkeeping information.

See SendDownloadACK (sa) extended option and Send Download Acknowledgement synchronization parameter.

When testing your synchronization scripts, you should add logic to your end_download script that causes occasional failures. This ensures that your scripts can handle a failed download.

Using non-blocking download acknowledgement

Bookkeeping information about what is downloaded must be maintained in the nonblocking downloaded acknowledgement transaction. This information should be updated in the publication_nonblocking_download_ack or nonblocking_download_ack scripts which is called after the remote database successfully applies the download.

If a failure occurs or SendDownloadAck is OFF, these non-blocking download acknowledgement scripts are not called and the download timestamp is not updated. When testing your synchronization scripts you should add logic to your publication_nonblocking_download_ack or nonblocking_download_ack script that causes occasional failures. This ensures that your scripts can handle a failed download.


Resuming failed downloads