No conflict detection   Choose this option if you do not want any conflict detection. Uploaded updates are applied without checking for conflicts. This avoids having to fetch current row values from the consolidated database, so the synchronization of updates may be faster.

Row-based conflict detection   A conflict is detected if the row has been updated by both the remote and consolidated databases since the last synchronization.

This option defines an upload_fetch script and upload_update script. See Detecting conflicts with upload_fetch scripts.

Column-based conflict detection   A conflict is detected if the same column has been updated for the row in both the remote and consolidated databases.

This option defines an upload_fetch_column_conflict script. See Detecting conflicts with upload_fetch scripts.

If a table has BLOBs and you choose column-based conflict detection, row-based conflict detection is used.

Consolidated   First in wins: uploaded updates that conflict are rejected.

Remote   Last in wins: uploaded updates are always applied.

Only use this option with column-based conflict detection. Otherwise, you get the same results and better performance by choosing no conflict detection.

Timestamp   The newest update wins. To use this option, you must create and maintain a timestamp column for the table. This timestamp column should record the last time that a row was changed. The column should exist on both the consolidated and remote databases. To work, your remote and consolidated databases must use the same time zone (preferably UTC) and their clocks must be synchronized.

Custom   You write your own resolve_conflict scripts. You do this in the Events tab after the wizard completes.

See Resolving conflicts with resolve_conflict scripts.