Remote IDs

The remote ID uniquely identifies a remote database in a MobiLink synchronization system.

When a SQL Anywhere or UltraLite database is created, it is given a remote ID of null. When the database synchronizes with MobiLink, the MobiLink client checks for a null remote ID. If it finds a null remote ID, it assigns a GUID as the remote ID. Once set, the database maintains the same remote ID unless it is manually changed (changing a remote ID manually is not recommended).

For SQL Anywhere remote databases, the MobiLink server tracks synchronization progress by remote ID and subscription. For UltraLite databases, the MobiLink server tracks synchronization progress by remote ID and publication. This information is stored in the ml_subscription system table. The remote ID is also recorded in the MobiLink server log for each synchronization.

Remote IDs must be unique

Each remote database must be uniquely identified by its remote ID. The built-in GUID remote ID accomplishes this. For an alternative, more human-readable identifier to represent a remote database in your scripts and business logic, consider using the MobiLink username and/or a unique authentication parameter. If you must assign your own remote IDs, then you must ensure that each remote database is assigned a unique remote ID.

If the same remote ID is used in two or more concurrent synchronizations, it can potentially cause corruption and/or data loss, depending on your synchronization scripts and business logic. Concurrent synchronizations with the same remote ID can happen for either of the following reasons:

A remote database has been assigned a duplicate remote ID. In this case the duplicate remote ID must be set to a unique remote ID.
A network error disconnects the client, which synchronizes again immediately. It is possible for both the original and the new synchronization to be processed at the same time.

In either case, the MobiLink server automatically tries to prevent corruption or data loss. To do this, MobiLink server typically cancels all but one of the concurrent synchronizations with an error.

Caution

Be careful about reusing remote IDs. If you re-use a remote ID, for example when replacing or restoring a remote database, call the ml_reset_sync_state stored procedure in the consolidated database for that remote ID prior to the first synchronization of the replacement remote database. For more detailed information, see ml_reset_sync_state system procedure.

Remote IDs

Remote IDs must be unique

Caution

See also