To ensure the integrity of synchronizations, dbmlsync must ensure that no changes downloaded from the server modify rows in the remote that have been changed since the last upload was sent. By default, it usually does this without locking any tables so the impact on other concurrent users of the database is minimized. Tables are locked IN SHARE MODE when synchronizing a publication that uses scripted upload or when the sp_hook_dbmlsync_schema_upgrade hook is defined.

When tables are not locked, dbmlsync tracks all rows that are modified after the upload is built. If the download contains a change for one of these rows that is considered a conflict.

If a conflict is detected, the download phase is canceled 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 optionConflictRetries (cr) extended option. --------------------------------------------------------------------------------

 -d option

 LockTables option