Rejects changes to the data in JSDO memory for the specified table reference or for all table references of the specified JSDO.
If the method succeeds, it returns true. Otherwise, it returns false.
Note: This method is most useful when the JSDO autoApplyChanges property is set to false. In this case, you typically invoke this method after calling the saveChanges( ) method in order to cancel a series of changes that have failed on the server. If the autoApplyChanges property is true, the JSDO automatically accepts or rejects changes for the specified table reference, or for all table references of the specified JSDO, based on the success of the corresponding record-change operations on the server resource.
Note: Rejecting all pending changes in JSDO memory—or even pending changes for a single table reference—because only some were unsuccessful on the server might be too broad an action for your application. If so, consider using rejectRowChanges( ) to reject changes a single table record at a time. For more information, see the description of rejectRowChanges( ) method.
A reference to the JSDO. If you call the method on jsdo-ref, the method rejects changes for all table references in the JSDO.
table-ref
A table reference on the JSDO. If you call the method on table-ref, the method rejects changes for the specified table reference.
When you reject changes on a table reference, this method backs out all pending changes to the record objects in the specified table in JSDO memory, and uses any before-image data to return each record to its original data values before the pending changes were made. When you reject changes on the JSDO reference, the method backs out all pending changes to the record objects in all tables of the JSDO, and uses any before-image data to return each record to its original data values before the pending changes were made. As the specified changes are rejected, the method also empties any associated before-image data, clears all associated error message settings, and removes the associated pending record change indications from JSDO memory.
Note: Regardless if you call rejectChanges( ), any error message settings that result from Data Object resource operations invoked by the most recent execution of the fill( ) or saveChanges( ) method remain available for return by the getErrors( ) method until the next execution of either fill( ) or saveChanges( ). For more information, see the getErrors( ) method description.
This method is especially useful for a resource that supports before-imaging (such as an OpenEdge ProDataSet) and handles the results of all record changes sent using a Submit operation as part of a single server transaction that undoes all the record changes in response to any single record-change error. When the Submit operation returns with an error, calling this method ensures that JSDO memory is synchronized with all the record changes that were undone as part of the server transaction.
Note: After this method rejects changes, and if you have set up automatic sorting using the autoSort property, all the record objects for affected table references are sorted accordingly. If the sorting is done using sort fields, any string fields are compared according to the value of the caseSensitive property.
Caution: If you have already successfully applied these changes on the server using the saveChanges( ) method, do not invoke this method if you want the affected client data to be consistent with the corresponding data on the server.
Example
The following code fragment shows a JSDO created so it does not automatically accept or reject changes to data in JSDO memory after a call to the saveChanges( ) method. Instead, it subscribes a handler for the JSDO afterSaveChanges event to determine if all changes to the eCustomer table in JSDO memory should be accepted or rejected based on the success of all resource Create, Update, and Delete operations on the server. To change the data for a record, a jQuery event is also defined on an update button to update the corresponding eCustomer record in JSDO memory with the current field values entered in a customer detail form (#custdetail):
function onAfterSaveCustomers(jsdo, success, request) {
if (success) {
jsdo.eCustomer.acceptChanges();
// Additional actions associated with accepting the pending changes...
}
else {
jsdo.eCustomer.rejectChanges();
// Additional actions associated with rejecting the pending changes...
}
}
When the update button is clicked, the event handler uses the findById( ) method to find the original record (jsrecord) with the matching internal record ID (#id) and invokes the assign( ) method on jsrecord with an empty parameter list to update its fields in eCustomer with any new values entered into the form. You might define similar events and controls to delete eCustomer records and add new eCustomer records.
An additional jQuery event also defines a save button that when clicked invokes the saveChanges( ) method to apply all pending changes in JSDO memory to the server. After the method completes, and all results have been returned to the client from the server, the JSDO afterSaveChanges event fires, and if any resource operations on the server were not successful, the handler calls rejectChanges( ) to reject all pending eCustomer changes in JSDO memory.
Note: This example shows the default invocation of saveChanges( ), which invokes each resource record-change operation, one record at a time, across the network. For a resource that supports before-imaging (such as an OpenEdge ProDataSet), you can also have saveChanges( ) send all pending record change operations across the network in a single Submit operation. For more information and an example, see the description of the saveChanges( ) method.