Generally, committing in Forms at runtime performs a form-level commit of all pending changes to the database. This commit takes into account all records in all data blocks that have been reserved for an insert, an update, or a delete operation. Specifically, issuing a COMMIT, COMMIT_FORM, or DO_KEY('COMMIT_FORM') will commit any DML present within the Forms triggers, as well as any records in the form that have been marked for the insert, update, or delete operations in the form. Sometimes, there might be a need to commit only the DML present in form triggers such as INSERT, UPDATE, or DELETE statements and ignore all other pending database changes in the form. In other words, ignore the default insertion, update, or deletion taken care of by Forms. Nullifying these forms operations in ON-INSERT, ON-UPDATE, or ON-DELETE triggers disables the default committing for good.
To commit only on the server side from Forms, there is a simple but powerful trick of the trade: Use FORMS_DDL('COMMIT'), as follows (do not place a semicolon after the COMMIT ):
BEGIN FORMS_DDL('COMMIT'); IF NOT FORM_SUCCESS THEN MESSAGE(TO_CHAR(DBMS_ERROR_CODE)''DBMS_ERROR_TEXT); END IF; END;
This code commits exclusively on the server side, and any pending changes in the form are unsaved. To check the success or failure of the COMMIT, the code after the FORMS_DDL does the job.
Any INSERT, UPDATE, or DELETE operations can be carried out using FORMS_DLL in addi tion to DDL.
Anonymous PL/SQL blocks and stored subprograms can be executed by placing them within a BEGIN and END. Do place a semicolon at the end of END while doing PL/SQL.
Advanced GUI Development: Developing Beyond GUI
Advanced Forms Programming
Object-oriented Methods in Forms
Intelligence in Forms
Additional Interesting Techniques
Working with Trees
Oracle 8 and 8i Features in Forms Developer