When working on a local subset of server data, you are working in isolation from the data source. Between the time that the local subset is provided, and the time that you attempt to save updates back to the data source, various situations may arise that must be handled by the resolver logic. For example, when you attempt to save your changes, you may find that the same information on the server has been updated by another user. Should the resolver save the new information regardless? Should it display the updated server information and compare it with your updates? Should it discard your changes? Depending on your application, the need for resolution rules will vary.
The logic involved in resolving updates can be fairly complex as errors can occur while saving changes, such as violation of server integrity constraints and resolution conflicts. A resolution conflict can happen from deleting a row that is already deleted, or updating a row that has been updated by another user. JBuilder provides default handling of these errors by positioning the DataSet to the offending row (if it's not deleted) and displaying the error encountered with a message dialog.
When resolving changes back to the data source, these changes are normally batched in groups called transactions. The JBCL uses a single transaction to save all inserts, updates, and deletions made to the DataSet back to the data source by default. To allow you greater control, JBuilder allows you to change the default transaction processing.
The JBCL also provides a generic resolver mechanism consisting of base classes and interfaces. You can extend these to provide custom resolver behavior when you need greater control over the resolution phase. This generic mechanism also allows you to create resolvers for non JDBC data sources that typically do not support transaction processing.
The following topics are included in this chapter: