Update conflicts cannot happen when data is shared for reading, or when each row (as identified by its primary key) is updated at only one database. Update conflicts only occur when data is updated at more than one database.
To replicate UPDATE statements, SQL Remote issues a separate UPDATE statement for each row. These single-row statements can fail for one of the following reasons:
The row to be updated differs in one or more of its columns When one of the values expected to be present has been changed by some other user, an update conflict occurs.
On remote databases, the update takes place regardless of the values in the row.
On the consolidated database, SQL Remote allows conflict resolution operations to take place. For example, when a conflict is detected, the consolidated database can:
UPDATE statement conflicts do not apply to primary key updates. You should not update primary keys in a SQL Remote system. Primary key conflicts must be excluded from the system by proper design.
The row to be updated does not exist Each row is identified by its primary key values. If the row has been deleted or if a primary key has been altered by another user, the row to be updated cannot be found.
On remote databases, the update does not occur.
On the consolidated database, the update does not occur.
A table without a primary key or uniqueness constraint refers to all columns in the WHERE clause of replicated updates When two remote databases make separate updates to the same row and replicate the changes to the consolidated database, the first changes to arrive on the consolidated database are applied; changes from the second database are not applied.
As a result, databases become inconsistent. All replicated tables should have a primary key or a uniqueness constraint and the columns in the constraint should never be updated.
|Discuss this page in DocCommentXchange.
Send feedback about this page using email.
|Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1|