Modifying conflict detection and resolution

When a row is updated on both the remote and consolidated databases, a conflict occurs the next time the databases are synchronized.

You have the following options for detecting conflicts:

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 or upload_fetch_column_conflict 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 or upload_fetch_column_conflict scripts.

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

You have the following options for resolving conflicts:

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 and not be the same column used for timestamp-based downloads. 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.

In the left pane of Sybase Central, expand MobiLink 12, your MobiLink project name, Synchronization Models, and then select your synchronization model name.
Open the Mappings tab in the right pane.
In the Table Mappings pane, select a table mapping.
In the Conflict Detection dropdown list, choose None, Row-based, or Column-based. If you chose None, you are done.
If you chose Row-based or Column-based, choose Consolidated, Remote, Timestamp, or Custom from the Conflict Resolution dropdown list.
If you chose Timestamp conflict resolution, open the Conflict Resolution tab in the lower pane and enter the name of a timestamp column to use.
If you chose Custom conflict resolution, open the Events tab and write a resolve_conflict script for the table.