Never update primary keys in synchronized tables. Updating primary keys defeats the purpose of a primary key because the key is the only way to identify the same row in different databases (remote and consolidated) and the only way to detect conflicts.
Conflicts can arise during the upload of rows to the consolidated database and are not the same as errors. When conflicts can occur, you should define a process to compute the correct values, or at least to log the conflict. Conflict handling is an integral part of a well-designed application.
If an attempt to insert a row finds that the row has already been inserted, an error is generated.
If an attempt to delete a row finds that the row has already been deleted, the second attempt to delete is ignored.
If you need different behavior, you can implement it by defining one or more of the upload events that are described in this section.
During the download stage of a synchronization, no conflicts arise in the remote database. If a downloaded row contains a new primary key, the values are inserted into a new row. If the primary key matches that of a pre-existing row, the values in the row are updated.
Discuss this page in DocCommentXchange.
|Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1|