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 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.
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. 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.
To customize conflict detection and resolution
In Model mode, open the Mappings tab.
In the Table Mappings pane, select a remote table.
In the Cflt. Det 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 Cflt. Res dropdown list.
If you choose Timestamp conflict resolution, open the Conflict Resolution tab in the lower pane and enter the name of a timestamp column to use.
If you choose Custom conflict resolution, open the Events tab and write a resolve_conflict script for the table.
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|