Store-record event |
|
|
|
A store-record event is for a record (or: row) in an application table. During user interaction, a store-record event occurs whenever: •The user leaves a record in the table after entering or changing the column value in it, for example, by navigating to a different record in the same table or in a different table, or by attempting to close the window or page carrying the record. •The user performs an action implying commit, such as choosing File, Save from the menu. During constraint evaluation, a store-record event occurs whenever: •A constraint effectively manipulates the record (by supplying or changing at least 1 new or changed column value in it) as part of the execution of an INSERT or UPDATE manipulation. Store-record events activate single-record constraints and transitional constraints. Raising a store-record eventThe occurrence and handling of store-record events is fully transparent in the USoft Rules Engine, but you can programmatically force this event to occur. The USoft GUI tools have scripting commands for raising the store-record event explicitly. Default USoft runtime menus often have an option for raising the store-record event. In default client/server application menus, choose Record, Store Record. TerminologyThroughout this explanation, record and row are used interchangeably. Record is not a physical record in a database table, but rather a record instance or record object constructed in memory as part of a table instance being processed. This record instance may have been initially queried from the database, and it translates back into a physical database record if and when the transaction commits. Row event is a synonym of store-record event. Save local is an older term for store-record event. StructureThe structure of a store-record event is visualised in the picture below. The event starts by executing update-on-self corrections (if any are defined) to the record being processed. Next, the record is subjected to row checks (if any are defined). Then, if there are other records that will need to undergo transaction checks as a result of this store-record event, these records are identified and signalled on the transaction checklist. Finally, the record being processed is stored internally. Up to this point, processing has been a linear operation within the record being processed. The next step is the executing of cascade-to-other corrections. These "go out" to other record instances. For each record affected, a separate store-record event is raised. This may causes a recursive "ripple" effect that finishes only when no further cascade-to-other corrections are found. The recursive nature of this process is visualised by the arrows on the left-hand side.
See also |
|
