Database application development is a feature of JBuilder Professional and Enterprise. Distributed application development is a feature of JBuilder Enterprise.
After data has been retrieved from a data source, and you make changes to the data in the StorageDataSet
, you will want to save the changes back to your data source. All recorded changes to a DataSet
can be
saved back to a data source such as a SQL server. This process is called resolving. Sophisticated built-in reconciliation technology deals with potential edit conflicts.
Between the time that the local subset of data is retrieved from a data source, 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. Errors can occur while saving changes, such as violations of server integrity constraints and resolution conflicts. A resolution conflict may occur, for example, when deleting a row that has already been 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 DataExpress mechanism 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.
DataExpress 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 discuss the options for resolving data:
When a master-detail relationship has been established between two or more data sets, special resolving procedures are required. For more information, see "Saving changes in a master-detail relationship".
"Saving changes back to your data source with a stored procedure" covers resolving changes made to a ProcedureDataSet
back to its data source.
"Using DataSets with RMI" provides a way to stream the data of a DataSet
by creating a Java Object (DataSetData
) that contains data from a DataSet
.
"Customizing the default resolver logic" describes how to set custom resolution rules using the QueryResolver
component and resolver events.
"Exporting data" describes how to export data to a text file.