A commit event is for a transaction as part of a session during which a user is connected to a USoft application.
During user interaction, a commit event occurs whenever:
•The user performs an action implying commit, such as choosing File, Save from the menu.
During constraint evaluation, a commit event does not occur. Constraints are activated by commit events but do not raise commit events.
Commit events activate multi-record restrictive constraints.
Raising a commit event
While the raising of a commit event is typically user-initialited, its handling is fully transparent in the USoft Rules Engine.
You can programmatically force this event to occur. The USoft GUI tools have scripting commands for raising the commit event explicitly. In client/server applications, choose File, Save. Default USoft runtime menus typically have an option for raising the commit event.
Commit event is, to all extents and purposes, equivalent to a COMMIT command in terms of the RDBMS.
We are using the phrase commit event in these help topics for the special purpose of distinguishing types of events that cause constraints to be evaluated.
In windows and pages facing end users, a range of different verbs is used, including Save, Send, Confirm, Commit, and Submit.
The structure of a commit event is visualised in the picture below. The event starts by subjecting records to transaction checks made necessary by multi-record restrictive constraints as well as deferred single-record restrictive constraints (if any such constraints have been defined). This process is optimised as much as possible by using a transaction checklist of records affected. This list was compiled earlier during store-record events within the transaction.
If the transaction passes all transaction checks, the next step is to commit the manipulations to the database.
If constraints have been defined with Deferred = Post Commit, this leads to chained corrections. These will raise new field-validation events and store-record events within the next transaction.