Siebel Remote and Replication Manager Administration Guide > Troubleshooting Remote and Replication Manager >

About Merge Conflicts Related to Assignment Manager

If the LogTxnChgOnly (Log transaction on change only) parameter for Assignment Manager is set to True, your Siebel Remote implementation may log an unusually high number of merge conflicts. You can safely ignore many of these merge conflicts. The following paragraphs describe why this phenomenon occurs, and provide an example of a sequence of events that produces such merge conflicts. For information about how you can distinguish between harmless merge conflicts and merge conflicts that do concern your data, see Distinguishing Between Harmless and Meaningful Merge Conflicts.

Why LogTxnChgOnly Affects the Quantity of Merge Conflicts

When LogTxnChgOnly is set to True, Assignment Manager does not log transactions for changes that only affect the ASGN_DT field for a record. The ASGN_DT field records the most recent date and time that Assignment Manager assigned that record. This field is not normally visible in Siebel applications.

Since transactions are not logged when only the value of the ASGN_DT field changes, these changes are not sent to Mobile Web Clients. Not sending these changes causes a discrepancy between the version of the record stored on the server and the versions stored in Mobile Web Client databases. The discrepancy causes no immediate problem, since it does not affect any of the visible data fields for the record. Allowing such harmless discrepancies can vastly reduce the amount of data that must be transferred to a Mobile Web Client during synchronization.

However, if Assignment Manager updates visible data fields in the record at a later time, a transaction is logged. In this case, the discrepancy in ASGN_DT field values is detected during the Mobile Web Client's next synchronization attempt, and is reported as a merge conflict.

Example of a Sequence of Events that Produces a Harmless Merge Conflict

The following paragraphs describe an example of a sequence of events that produces a harmless merge conflict. For clarity, the value of the ASGN_DT field is shown here as a date only, although the field actually includes both date and time.

1. The server runs Assignment Manager and changes the value of several fields in record X, including setting the value of field ASGN_DT to 2003-10-29. Because values are changed in one or more visible fields, a transaction is logged.
2. A Mobile Web Client synchronizes and receives the updated values for all fields in record X, including the value of 2003-10-29 for the ASGN_DT field.
3. The server runs Assignment Manager and changes the value of the ASGN_DT field to 2003-10-30, but does not change values in any visible fields, so no transaction is logged. The change to the value of the ASGN_DT field is not transmitted to the Mobile Web Client.
4. The server runs Assignment Manager and changes the value of several fields in record X, including setting the value of field ASGN_DT to 2003-10-31. Because values are changed in one or more visible fields, a transaction is logged.
5. The Mobile Web Client synchronizes and receives the updated values for all fields in record X, including the value of 2003-10-31 for the ASGN_DT field. This causes a conflict, because the transaction updates the value of the ASGN_DT field from 2003-10-30 to 2003-10-31, but the current value of ASGN_DT in the local database is 2003-10-29. The old value in the transaction does not match the current value in the local database, so a conflict is reported.