Resolve Concurrent Update Conflicts
A concurrent update conflict can occur in a multi-user environment when another user modifies a row in a particular table between the time you fetch the row from that table, and the time you modify and attempt to commit it.
This situation can occur because Edit does not apply locks to the rows until you actually modify and commit data. Fetching the data, regardless of whether you are browsing or editing, does not automatically apply locks. Typically, concurrent updates can occur when you:
- Update a modified row.
- Update a deleted row.
- Delete an updated row.
- Undo a change to an updated row.
When a concurrent update occurs, the Concurrent Update Resolution dialog displays the table name and the row in conflict. You can compare the current value of the row to the pending value you are committing. Select Proceed to apply your change to the row, or select Skip to ignore your change.
The Continue to notify for conflicts on a multi-row change check box is enabled when you perform a single operation that results in changes to many rows (for example, Replace All). To prevent displaying the Concurrent Update Resolution dialog as each row is updated, clear the check box. When the operation is complete, the check box resets to selected by default.
Although highly unlikely, it is possible that another user may modify a row while you are in the process of resolving a concurrent update for that row. If this happens, the row is placed in Error status in the Table Editor. You can revise your entries or undo the change that caused the error.
Optim™ Primary Keys
Unlike database primary keys, you can use Edit to define primary keys that are not unique. When you update or delete a row that has a non-unique primary key, Edit attempts to locate the row that matches the row in the current fetch set. If a matching row is found, the row can be updated or deleted. If a matching row is not found, the change is handled as a concurrent update.