JSDO properties, methods, and events reference : acceptChanges( ) method
  

acceptChanges( ) method

Accepts 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 accept a series of changes after they have been successfully applied to 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: Accepting all pending changes in JSDO memory—or even pending changes for a single table reference—because none raised an error from the server might be too broad an action for your application. If so, consider using acceptRowChanges( ) to accept changes a single table record at a time. For more information, see the description of acceptRowChanges( ) method.
Return type: boolean
Applies to: progress.data.JSDO class, table reference property (JSDO class)
Working record: The working record is set depending on the changes accepted.

Syntax

jsdo-ref.acceptChanges ( )
jsdo-ref.table-ref.acceptChanges ( )
jsdo-ref
A reference to the JSDO. If you call the method on jsdo-ref, the method accepts 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 accepts changes for the specified table reference.
When you accept changes on a table reference, this method makes the record objects in the specified table reflect all pending changes to them in JSDO memory. When you accept changes on the JSDO reference, the method makes the record objects in all tables of the JSDO reflect all pending changes to them in JSDO memory. As the specified changes are accepted, the method also empties any associated before-image data, clears all associated error message settings, and removes the associated record change indications from JSDO memory.
Note: Regardless if you call acceptChanges( ), 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 that are sent using a Submit operation as part of a single server transaction that successfully commits all the changes. When the Submit operation returns successfully, calling this method ensures that JSDO memory is synchronized with all the record changes that were committed in the server transaction.
Note: After this method accepts 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 pending JSDO changes that you need to apply to the server, be sure not to invoke this method before you invoke the saveChanges( ) method to successfully apply these changes to the server. Otherwise, the affected client data will be inconsistent 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):
dataSet = new progress.data.JSDO( { name: 'dsCustomerOrder',
                                    autoApplyChanges : false } );
dataSet.eCustomer.subscribe('afterSaveChanges', onAfterSaveCustomers, this);

$('#btnUpdate').bind('click', function(event) {
  var jsrecord = dataSet.eCustomer.findById($('#custdetail #id').val());
  if (jsrecord) {jsrecord.assign();};
});

// Similar controls might be defined to delete and create eCustomer records...

$('#btnSave').bind('click', function(event) {
  dataSet.saveChanges();
});

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.
A 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 all resource operations on the server were successful, the handler calls acceptChanges( ) to accept the pending changes to eCustomer in JSDO memory. For more information on how this same example determines when and how to reject changes, see the description of the rejectChanges( ) method.
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.

See also:

acceptRowChanges( ) method, autoApplyChanges property, autoSort property, caseSensitive property, rejectChanges( ) method, saveChanges( ) method