Designing Windows › Event Actions › Event Action Characteristics

Event Action Characteristics

Event actions have the following characteristics:

• All event actions in a procedure step share the same views as the procedure step.
• We recommend you to perform entity actions in process or common action blocks and not directly in an event action. However, if you do choose to perform entity actions in an event action, you should limit them to READ and READ EACH only (no updates of any kind). Performing entity actions in action blocks also avoids the sharing of entity action views between event actions and between event actions and the procedure step. Sharing views may cause undesirable results with SQL optimization. For example, if you use the WHERE CURRENT OF construct with a READ statement, the READ action could fail. Additionally, if your logic performs update functionality (UPDATE, TRANSFER, ASSOCIATE, or DELETE statements), too many database locks may be generated. This does not affect data integrity, but response time may be unacceptable.
• By default, an event action moves import views to export views for all event types except the Changed event. With Changed events, the import view contains the current view of the data in the window and the export view contains the previous data. You can override the default for any event type by detailing an event action in the Action Diagram tool.
• Event actions never clear export views. When the main body of PrAD executes, the export views are cleared. Thus, an event action may begin execution with import values or export values that resulted from the execution of another event action.
• The logic in an event action executes without executing the logic in the entire PrAD. An event action cannot cause the procedure step in which it is included to execute. You can, however, set an exit state within an event action that causes a flow to another procedure step.
• CA Gen always places event actions after the main body of PrAD logic.
• The order of event actions in the PrAD is significant during Construction. Event actions produce entry points into the source file. Therefore, if you reorder event actions within a PrAD, you must regenerate the Window Manager and the procedure step.
• An implied commit point occurs when an event action completes execution, unless the event action sets an exit state that causes a rollback.
• An event action cannot be nested within another event action. A user-defined event, however, can trigger another event with the use of the special external action block TIREVENT. Refer to the online help for a complete discussion of user-defined events and TIREVENT.