Blog Viewer

Whether the user has opened an existing record or created a new one, chances are they are going to change some data on the screen and then save it. Users save by clicking the Save button, which triggers the application to complete the save lifecycle. The application responds depending on whether it finds hard errors:

• No hard errors: Displays a message that the data was saved.
• Hard errors: Displays a message informing the user why the data was not saved.

1. The user clicks the Save button.
2. The business tier receives the modified object, utlResponseData, from the webserver.
3. The business tier retrieves the business object from the database and binds the modified values to it.
4. The business tier calls the BeforeValidate method on the main business object. You can override this if you want to load values before you validate the form's hard errors.
5. The business tier calls the ValidateHardErrors method on the main business object. This is the method that determines whether the application can persist data. If there are no hard errors, the application does persist data. In the default save method, finding hard errors ends the lifecycle here with a message to the user that the data did not save because of errors.
6. The business tier calls the BeforePersist method on the business object. You can override this if you want the application to do something before it persists changes.
7. The business tier calls the PersistChanges method on the business object. This method calls the UpdateDataObject method for each data object associated with the form, which persists the data based on the object state (insert, update, or delete).
8. The business tier calls the ValidateSoftErrors method on every business object that is modified. This method executes soft error validations from the form's business object. If it finds any errors, it inserts them into the business object's errors table.
9. The business tier calls the ValidateChecklist method on every business object that is modified. This method executes checklist validations from the form's business object. If it finds any errors, it inserts them into the checklist table.
10. The business tier calls the UpdateValidateStatus method on every business object that is modified. This method updates the form's status column according to the validations run in previous steps.
11. The business tier calls the AfterPersist method on the main business object. You can override this if you want the application to do something after it persists changes.
12. The business tier calls the EvaluateInitialLoadRules method on the main business object. This method executes the initial load validations from the form's business object to validate data that automatically changed when the user saved.
13. If the page mode was new, the business tier changes it to update.
14. The response is created as utlResponseData and the business object is stored in the database.
15. The webserver sends utlResponseData to the browser.
16. The browser binds the data to the form.
17. The user sees a message that the data saved.

There are other save lifecycles besides the default:

• Force Save: Persists data even if there are hard errors.
• Save and New: Executes the save lifecycle, then creates a new record.
• Save and Next: Executes the save lifecycle, then navigates to the next record if multiple records are open.
• Save Ignore ReadOnly: Executes the save lifecycle when the record is read-only for all controls whose Ignore Read Only property is true.
• Save No Changes: Persists data even if there are no changes to the data.

This post is part of the Maintenance Form topic. Click here to open the Maintenance Form Overview.