Download failure is caused by a communication error during the download or a user cancelling the download. The MobiLink server holds download data that has not been received by the client for use in a restartable download. You can reduce the probability of download failure by decreasing the maximum amount of data allocated for restartable downloads using the -ds option. The server does not release download data until one of the following occurs:
MobiLink has functionality that can assist with download failure recovery, and prevent retransmission of the entire download. This functionality has separate implementations for SQL Anywhere and UltraLite remote databases. See -ds option.
When synchronization fails during a download, the downloaded data is not applied to the remote database, however, the successfully transmitted download portions are stored in a temporary file on the remote device. Dbmlsync uses this file to avoid lengthy retransmission of data, and to recover from download failure.
There are three ways to implement this functionality. In all cases, dbmlsync aborts and the resumed download fails if there is any new data to be uploaded.
-dc After a download fails, use -dc the next time you start dbmlsync to resume the download. If part of the failed download was transmitted, the MobiLink server only transmits the remainder of the download.
For more information, see -dc option.
ContinueDownload (cd) extended option When used on the dbmlsync command line, the cd extended option works just like the -dc option. You can also store this option in the database, or use sp_hook_dbmlsync_set_extended_options to set this option in a single synchronization.
sp_hook_dbmlsync_end hook You can use the restart parameter to cause a download to resume. You know a download is resumable if the restartable download parameter is set to true. You can also create logic in the hook to resume a download if a download file exists and is a certain size.
You can control the behavior of UltraLite applications following a failed download as follows:
The UltraLite database may be in an inconsistent state at this point. Depending on your application, you may want to ensure that synchronization completes successfully or is rolled back before you allow changes to the data. See Keep Partial Download synchronization parameter, and Partial Download Retained synchronization parameter.
The restarted synchronization does not perform an upload, and downloads only those changes that would have been downloaded by the failed download. That is, it completes the failed download but does not synchronize changes made since the previous attempt. To get those changes, you need to synchronize again once the failed download has completed, or call Rollback Partial Download and synchronize with Resume Partial Download set to false.
When you restart the download, many of the synchronization parameters from the failed synchronization are used again automatically. For example, the publications parameter is ignored: the synchronization downloads those publications requested on the initial download. The only parameters that must be set are the Resume Partial Download parameter (which must be set to true) and the User Name parameter. In addition, settings for the following parameters are obeyed, if set:
You may want to roll back the changes from a failed download if synchronization cannot be completed, for example if the server or network is unavailable, and if you want to maintain a consistent set of data while letting the end user continue to work.
For more information about communications errors, see Error Messages.
If the send_download_ack synchronization parameter is set to true, the setting is ignored for the resumed download.
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|