Although an application can include more than one form module, it can process only one database transaction at a time. A commit operation in a form commits updates, inserts, and deletes pending for the entire application session, rather than for any individual form in the application. This means that a commit issued by Form B can commit changes that were posted by Form A. Similarly, a rollback command can roll back changes that were posted in forms other than the current form.
When you build an application with multiple forms, you can use posting and rollback mode to control commit processing across called forms.
When changes are posted in the calling form, the called form does not run in post-only mode, and end users can issue a commit from the called form. The following steps illustrate this sequence, and show how posting allows a called form to commit changes that were made in the calling form:
/* EXAMPLE 1: Committing from a Called Form
** Oracle Forms runs called forms in post-only mode when there
** are unposted changes in the calling form. Although post-only
** mode is useful in many applications, externalizing it to
** end-users can add complexity to your application's interface.
** For some applications, it may be better to prevent forms
** from running in post-only mode altogether. To do so, design
** the application so changes are explicitly posted before
** another form is called. To post changes in a form, execute
** the POST Built-in procedure just prior to calling a form
** with the CALL_FORM or NEW_FORM procedure. For example, you
** can include the POST procedure in the menu item command or
** When-Button-Pressed trigger that calls the next form:
*/
POST;
IF (system.form_status <> 'QUERY') THEN
CALL_FORM('form_b', no_hide);
END IF;
/* EXAMPLE 2: Committing Changes in the Calling Form
** from the Called Form
**
** Use posting to allow a calling form to commit changes posted in
** a called form. The following steps illustrate this sequence:
**
** 1. Update or delete records in Form A.
** 2. Call Form B. (Form B is in post-only mode because changes
** were made in Form A that were not explicitly posted.)
** 3. Insert, update, or delete records in Form B.
** 4. Post in Form B.
** 5. Exit Form B with NO_ROLLBACK parameter.
** 6. Commit in Form A. (This commits changes made in Form A and
** changes posted in Form B.)
**
** When Form B exits and returns control to Form A (step 5),
** the rollback mode is set to NO_ROLLBACK to preserve changes
** that were posted in Form B.