Accepts changes to the data in JSDO memory for a specified record object.
This can be the working record of a table reference or the record specified by a JSRecord object reference. 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 might invoke this method in the callback for the corresponding JSDO event fired in response to a successful record-change operation on the server resource that was invoked by executing the saveChanges( ) method. If the autoApplyChanges property is true, the JSDO automatically accepts or rejects changes to the record object based on the success of the corresponding resource operation on the server.
A reference to a JSRecord object for a table reference in JSDO memory.
You can obtain a JSRecord object by:
Invoking a JSDO method that returns record objects from a JSDO table reference (find( ), findById( ), or foreach( ))
Accessing the record property on a JSDO table reference that already has a working record.
Accessing the record parameter passed to the callback of a JSDO afterCreate, afterDelete, or afterDelete event.
jsdo-ref
A reference to the JSDO. You can call the method on jsdo-ref if the JSDO has only a single table reference, and that table reference has a working record.
table-ref
A table reference on the JSDO that has a working record.
When you accept changes on a specified record object, this method makes the record reflect all pending changes to it in JSDO memory. As the specified changes are accepted, the method also empties any associated before-image data, clears any associated error message setting, and removes the associated pending change indications from JSDO memory.
Note: Regardless if you call acceptRowChanges( ), 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.
Note: After this method accepts changes on a record, and if you have set up automatic sorting using the autoSort property, all the record objects for the affected table reference 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. 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 single handler for each of the afterDelete, afterCreate, and afterUpdate, events to determine if changes to any eCustomer table record in JSDO memory should be accepted or rejected based on the success of the corresponding resource operation on the server. To change the data for a record, a jQuery event is also defined on a save button to update the corresponding eCustomer record in JSDO memory with the current field values entered in a customer detail form (#custdetail):
$('#btnSave').bind('click', function(event) {
var jsrecord = dataSet.eCustomer.findById($('#custdetail #id').val());
if (jsrecord) {jsrecord.assign();};
dataSet.saveChanges();
});
// Similar controls might be defined to delete and create eCustomer records...
function onAfterCustomerChange(jsdo, record, success, request) {
if (success) {
record.acceptRowChanges();
// Perform other actions associated with accepting this record change
}
else
{
record.rejectRowChanges();
}
}
When the button is clicked, the event handler uses the findById( ) method to find the original record 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. It then calls the saveChanges( ) method to invoke the resource Update operation to apply these record changes to the server. You might define similar events and controls to delete the eCustomer record or add a new eCustomer record.
After each resource operation for a changed eCustomer record completes, results of the operation are returned to the client from the server, and the appropriate event fires. If the operation was successful, the handler calls acceptRowChanges( ) to accept the record change associated with the event in JSDO memory. An advantage of using an event to manually accept a record change is that you can perform other actions associated with accepting this particular change, such as creating a local log that describes the change.
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.
Invoking a JSDO method that returns record objects from a JSDO table reference (find( ), findById( ), or foreach( ))