When working with client-server software, there is always a risk of multiple versions of the same data circulating among employees. Concurrent users often choose to update simultaneously, and as a result create multiple inaccurate versions of the same key data in a database.

Detecting Data Conflicts

DataSplice provides the administrator with fine-tuned control over how conflicts are detected. Before the server attempts any data modification it will first query the record to see if it has changed behind the scenes since the client initially downloaded the data.

The Administration Client can be used to set whether or not each field in a view should trigger a conflict if it has been modified. This supports several different scenarios:

• Check every field in a record so that all concurrent changes trigger a conflict.
• Check only the timestamp or a similar field that is modified each time a record is changed.
• Check a sub-set of fields, so important fields trigger conflicts but others allow the edit to continue.

Fields might be set to ignore checksums for two reasons. First, it might not matter if data for the field is overridden, either because the information is not critical in the first place or there is no concept of conflict (for instance with a meter reading). The other reason is if the database procedures implementing the business logic can handle the conflict automatically.

Conflict Resolution

For any conflicts that remain unresolved by the server, DataSplice will assist the client to resolve the problem. DataSplice presents the user with a screen that shows three different records side by side, including the current database version, user's modified version, and the values record sent to the client during initial download.

Each field that produced a conflict is highlighted. The user can then edit the database version to merge the changes so they can be resubmitted. Or, if the changes are no longer relevant given the behind the scenes changes, the user can cancel the edit altogether.