How download timestamps are generated and used

MobiLink generates and uses a timestamp for timestamp-based downloads as follows:

  • After an upload is committed and immediately before invoking the prepare_for_download event, the MobiLink server fetches the current time from the consolidated database and saves the value. This timestamp value represents the start time of the current download; the next synchronization should only download data that changes after this time.
  • The MobiLink server sends this timestamp value as part of the download, and the client stores it.
  • The next time the client synchronizes, it uses the timestamp value for the last_download_timestamp that it sends with the upload.
  • The MobiLink server passes the last_download_timestamp that the client just uploaded into your download_cursor and download_delete_cursor. Your cursor can then select changes with timestamps that are newer or equal to the last last_download_timestamp to ensure that only new changes are downloaded.
Where the last download time is stored

The last download time is stored on the remote database. This is the appropriate place because only the remote knows if the download has been successfully applied.

For SQL Anywhere remotes, the last download time is stored per subscription. See SYSSYNC system view.

For UltraLite remotes, the last download time is stored per publication. See syspublication system table.

Changing the last download time

In some rare circumstances you may want to modify the last_download_timestamp. For example, if you accidentally delete all the data on a remote database, you can resynchronize it by defining a modify_last_download_timestamp connection script to reset the value for the last download timestamp. There is another event, called modify_next_last_download_timestamp, which you can use to reset the timestamp not for the current synchronization but for the next synchronization. See:

UltraLite also provides functionality to change the last download time from the remote. See:

See also