Wednesday, July 8, 2009

COMMIT_FORM built-in

Description

Causes Form Builder to update data in the database to match data in the form. Form Builder first validates the form, then, for each block in the form, deletes, inserts, and updates to the database, and performs a database commit. As a result of the database commit, the database releases all row and table locks.
If the end user has posted data to the database during the current Runform session, a call to the COMMIT_FORM built-in commits this data to the database.
Following a commit operation, Form Builder treats all records in all base-table blocks as if they are queried records from the database. Form Builder does not recognize changes that occur in triggers that fire during commit processing.

Syntax

PROCEDURE COMMIT_FORM;
Built-in Type restricted procedure
Enter Query Mode no


** Built-in: COMMIT_FORM
** Example: If there are records in the form to be
** committed, then do so. Raise an error if the
** commit was not successful.
*/
BEGIN
/*
** Force validation to happen first
*/
Enter;
IF NOT Form_Success THEN
RAISE Form_Trigger_Failure;
END IF;
/*
** Commit if anything is changed
*/
IF :System.Form_Status = 'CHANGED' THEN
Commit_Form;
/*
** A successful commit operation sets Form_Status back
** to 'QUERY'.
*/
IF :System.Form_Status <> 'QUERY' THEN
Message('An error prevented your changes from being
committed.');
Bell;
RAISE Form_Trigger_Failure;
END IF;
END IF;
END;

Example 2

/*
** Built-in: COMMIT_FORM
** Example: Perform Form Builder database commit during commit
** processing. Decide whether to use this Built-in
** or a user exit based on a global flag setup at
** startup by the form, perhaps based on a
**
** Trigger: On-Commit
*/
BEGIN
/*
** Check the global flag we set during form startup
*/
IF :Global.Using_Transactional_Triggers = 'TRUE' THEN
User_Exit('my_commit');
/*
** Otherwise, do the right thing.
*/
ELSE
Commit_Form;
END IF;
END;