Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Français) » MobiLink - Getting Started » Introducing MobiLink Technology » MobiLink models » Model mode


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 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.

    See Resolving conflicts with resolve_conflict scripts.

♦  To customize conflict detection and resolution
  1. In Model mode, open the Mappings tab.

  2. In the Table Mappings pane, select a remote table.

  3. In the Cflt. Det dropdown list, choose None, Row-based, or Column-based. If you chose None, you are done.

  4. If you chose Row-based or Column-based, choose Consolidated, Remote, Timestamp, or Custom from the Cflt. Res dropdown list.

  5. 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.

  6. If you choose Custom conflict resolution, open the Events tab and write a resolve_conflict script for the table.

See also