To ensure the integrity of synchronizations, dbmlsync must ensure that no rows in the download are modified between the time the upload is built and the time the download is applied.

On all platforms except Windows Mobile, by default, dbmlsync obtains a shared lock on all tables mentioned in any publication being synchronized. On Windows Mobile, by default, dbmlsync obtains an exclusive lock. Dbmlsync obtains the lock before it begins building the upload, and it maintains the lock until the download is applied.

For more information about locks, see Row locks.

The following options let you customize this locking behavior:

• -d option
• LockTables option

-d option

When using the locking mechanism, if other connections to the database exist and if these connections have any locks on the synchronization tables, then synchronization fails. If you want to ensure that synchronization proceeds immediately even if other locks exist, use the dbmlsync -d option. When this option is specified, any connections with locks that would interfere with synchronization are dropped by the database so that synchronization can proceed. Uncommitted changes on the dropped connections are rolled back.

For more information, see -d option.

LockTables option

An alternative way to protect data integrity is to set the extended option LockTables to OFF, which prevents an article's tables from being locked. This causes dbmlsync to track all rows that are modified after the upload has been built. When the download is received, it is not applied if any rows in the download have been modified. Dbmlsync then retries the synchronization. The retry succeeds unless a new download conflict is detected.

For more information, see LockTables (lt) extended option.

If a conflict is detected, the download phase is cancelled and the download operations rolled back to avoid overwriting the new change. The dbmlsync utility then retries the synchronization, including the upload step. This time, because the row is present at the beginning of the synchronization process, it is included in the upload and therefore not lost.

By default, dbmlsync retries synchronization until success is achieved. You can limit the number of retries using the extended option ConflictRetries. Setting ConflictRetries to -1 causes dbmlsync to retry until success is achieved. Setting it to a non-negative integer causes dbmlsync to retry for not more than the specified number of times.

For more information, see ConflictRetries (cr) extended option.