For any Data Object operation that completes with an error of any type (operation execution, web application, server, or network), the success property of the returned request object (and the success parameter passed to any event or Promise callback) is set to false. As noted in the previous topic (see Handling asynchronous and synchronous execution results), error information from operation execution can be found using two separate mechanisms:
Calling the getErrors( ) method on a JSDO table reference to return associated errors from the most recent call to fill( ) or saveChanges( ).
Inspecting the response and xhr properties of the request object for information on operation errors and on web application, web server, or network errors, respectively, from the most recent call to fill( ), saveChanges( ), or an invocation method.
Note that for a Data Object Create, Update, Delete (CUD), or for a Submit operation (on a before-image resource only), if any error, at any point causes the operation to complete unsuccessfully, by default (with the autoApplyChanges property set to true), the record or records in JSDO memory are reverted prior to any changes that caused the operation or operations to execute by invoking saveChanges( ), and the intended record changes are preserved as values of appropriate request object properties.
For example, a failed Create operation causes the added record to be removed from JSDO memory. The record object (or objects for Submit with before-imaging) that were originally added for the operation are then available for your re-use as the value of the jsrecord property (or for Submit with before-imaging, as the value of the jsrecords property) of the request object (or of the record parameter passed to the afterCreate event callback). A similar reversion occurs for the Update and Delete operations (or updated and deleted records of a Submit with before-imaging), with the field values of any updated record reverted to their original values, and any deleted record added back to JSDO memory. Again, the original updated or deleted record or records are available using the appropriate jsrecord or jsrecords property of the request object.
Note: When the Data Object resource (and operation) supports before-imaging, if a Data Object CUD or Submit operation completes with an error for a given record change applied to the server database, the associated record object can include a before-image error string as part of its data that can be set to a message describing the error. You can return this value, if defined, by invoking the getErrorString( ) method on the record object.
However, you can change this default behavior by setting the autoApplyChanges property to false. In this case, when the operation completes (successfully or unsuccessfully) you can manually accept or reject all, or selected, record changes in JSDO memory using one off the following methods:
acceptChanges( )
acceptRowChanges( )
rejectChanges( )
rejectRowChanges( )
Note that when autoApplyChanges is true, corresponding errors returned from a call to saveChanges( ) are cleared from JSDO local memory (and also the response and xhr properties of returned request objects) at the following points, which ever comes first:
Execution completes for the final callback subscribed to an operation event or registered to the Promise object returned by saveChanges( ).
A corresponding accept*Changes( ) or reject*Changes( ) method is executed.
However, if you need access to errors from the most recent call to fill( ) or saveChanges( ) beyond these points, you can return them for any associated JSDO table reference by calling getErrors( ), regardless of the setting of autoApplyChanges or the execution of accept*Changes( ) and reject*Changes( ) methods. These errors are thus available for return until the next call to either fill( ) or saveChanges( ).
For more information on handling errors for Data Object operations, see the descriptions of the methods that invoke these operations:
Calling the getErrors( ) method on a JSDO table reference to return associated errors from the most recent call to fill( ) or saveChanges( ).