Siebel Remote and Replication Manager Administration Guide > About Siebel Remote > Locks, Concurrency, and Conflicts >

Conflict Detection and Resolution

To support team selling and field service, Siebel Remote allows different users to access the same data. This situation creates the possibility that two users might make conflicting changes to the same data when they are disconnected from the Siebel Server. To automatically detect update conflicts, Siebel Remote compares transactions at the field level. It uses specific rules to resolve conflicts for the following data changes:

• Changes that update values in an existing row
• Changes that delete an existing row
• Changes that add a new row

More complex conflicts involve deleting and adding database rows. For example:

• One user might change a value in a database row and another user might delete the entire row.
• One user might add a database row to a local database but the primary key for this row might be in use by an existing row in the server database or in the local database of another remote client.

Data divergence is a situation that occurs when the local databases on different remote clients become less synchronized. Data divergence can occur if Siebel Remote does not detect or resolve these complex changes. To prevent data divergence, Siebel Remote uses conflict detection and resolution logic.

Update Conflict

An update conflict occurs if, for example, one user changes the area code for a contact to 415 and another user changes it to 408. Table 6 describes values you can use in the System Conflict Resolution field of the Remote System Preferences form to specify how to resolve conflicts. For more information, see Setting Preferences for Visibility, Logging, Timestamps, and Conflict Resolution.

If Siebel Remote rejects an update from a remote client, then the user can determine if an update conflict has occurred. If the result of the conflict resolution is not appropriate, then the user can manually reapply the change to the local database. Siebel Remote sends it again to the Siebel Server during the next synchronization session when the remote client sends database changes to the server. If other changes have not been made to the data value since the last synchronization session, then the change does not conflict and it succeeds on the server.

Siebel Remote processes transactions in the order in which the user synchronizes. For the purposes of conflict resolution, any successful database update that a remote client sends to the Siebel Server becomes a server transaction.

Insert Conflict

Although a user might successfully add a database row to a local database or to the server database, the added or inserted transaction might duplicate a new entry in another database that resides elsewhere and that the Siebel Server has not yet processed. If the user primary key of a new row matches the user primary key of an existing row, then Siebel Remote determines that an insert or duplicate conflict exists.

Siebel Remote cannot determine if the transaction is a true duplicate or simply an erroneous use of the same identifier for two different data entities. Siebel Remote cannot ignore the duplicate transaction. Instead, it adds the new row and sets the CONFLICT_ID column to the ROW_ID of the record. This configuration indicates that the row is a duplicate and makes sure the value for the _U1 index is unique. To determine if an insert conflict, also known as a duplicate conflict, has occurred, the user can examine the Remote Status view and watch for duplicates in regular data views, such as the Accounts view or the Contacts view.

For example, the user might change the user primary key and resend the update. When the user resolves the conflict Siebel Remote captures the local database update for transmission to and resynchronization with the Siebel Server during the next synchronization session.

The user must monitor and resolve any conflict that the Siebel Server creates. The conflict is visible as duplicate records in a regular data view, such as the Accounts view or the Contacts view. To resolve an insert conflict, the user can use the Merge Record feature to perform a merge on the duplicate records. This feature is available only after the user chooses more than two records in the applet. To use it, the user chooses the Edit menu, and then the Merge Records menu item.

To resolve the conflict, the user can also change the user keys of one of the duplicate records.

The user must resolve conflicts before you can use EIM to merge records. If the user does not resolve conflicts, then the conflict flag in the interface table columns is not accurate.

The local database treats a null value as a unique value. If the user leaves a key field null for two or more records, then the local database allows duplicates.

Delete Conflict

If the user deletes a row in the local database, then a potential delete conflict occurs. If Siebel Remote encounters a delete transaction, then it uses the following rule whether or not the transaction is in conflict with another update:

Delete Always Wins

If one transaction updates a database row and another transaction deletes this row, then Siebel Remote ignores the update and deletes the row.

The Delete Always Wins rule supersedes the System Conflict Resolution field of the Remote System Preferences form.

If the user synchronizes, and if the Merger Friendly Notification system preference is TRUE, then Siebel Remote displays deleted records in the Session Actions list of the Remote Status view of the User Preferences screen. For more information, see Process of Configuring System Preferences for the Siebel Server.

Merge Conflict

If Siebel Remote merges records separately on the remote client and on the Siebel Server, then a merge conflict occurs. The following example illustrates the problem:

1. Siebel Remote merges data from account A with data from account B on the remote client.
2. Siebel Remote merges data from account A with data from account B on the Siebel Server.
3. Delete transactions have the highest priority in Siebel Remote. The situation described in Step 1 and Step 2 can cause the following delete transactions:
   • One delete transaction from the remote client
   • One delete transaction from the Siebel Server
4. Siebel Remote deletes data from these accounts.

To avoid this problem, do not merge data on remote clients.