Transactional triggers and commit processing

Question

I have only been an active member of this thread for a couple of weeks and have tried to contribute to a few postings. But I have also noticed lots of postings relating to the use of DML statements inside what I would call non commit time triggers.
What I mean here is, for example, a WHEN-BUTTON-PRESSED trigger that does inserts, updates, deletes, followed by the COMMIT_FORM procedure.
I thought it might be useful to draw attention to the possible pitfalls of this approach. I'm not saying that this approach is wrong - far from it, but sometimes it means that people aren't leveraging the functionality that you get "for free" from Forms.
By coding some DML followed by a Commit_Form, you are not getting any rollback functionality from Forms. For example:
INSERT INTO A
INSERT INTO B
COMMIT_FORM;
Let's imagine that the insert into A worked but the insert into B failed for some reason. The user gets an unhandled exception. Now imagine that the cause of the error is cleared up, and the user presses the button (or whatever the invokation action was) again, and the commit works. You will have 2 records in A and 1 in B. You may not have expected that, and without coding your own rollback/savepoint that's what you would get.
You also (1) don't get a Working... message without coding it yourself, and (2) get the "No changes to commit" message; removing this is the subject of many threads on this site.
If you have a block which is based over a table which you need to update, then all of the DML statements ought to be coded inside PRE/POST/ON INSERT/UDPATE/DELETE statements, or other Forms transactional triggers (pre-database-commit etc..). If you need to change other tables then put the DML for them inside those triggers. Then you don’t have to worry about which records the user changed – if the user didn’t touch them then Forms won’t fire the triggers. And when you call the COMMIT_FORM procedure, Forms will fire the triggers for you and if any of them fail, it will rollback back to where the COMMIT_FORM started.
An example in 1 thread I saw this morning, was a Delete button, which was to delete the current record in a multi-record block. This button performed the “DELETE FROM <table> WHERE <key=:block.key>” followed by a Commit. Then of course the block needed to be re-queried to reflect the fact that the record had gone. Using the power of Forms to simply call the DELETE_RECORD procedure would have achieved the same result without needing to requery the block. And Forms would do the delete by ROWID, the fastest way of doing it.
If you don’t have a block based over a table, then you can consider creating a dummy block which uses Transactional Triggers. Code an ON-INSERT on that block which includes the DML you want to execute. Then in the trigger initiating the commit processing you would do something like:
:DUMMY_BLOCK.ITEM1 := ‘X’;
COMMIT_FORM;
IF (NOT FORM_SUCCESS) OR :SYSTEM.FORM_STATUS != ‘QUERY’ THEN
-- the commit failed
END IF;
Then you’ll get a nice Working.. message and full rollback control.
I think the moral of what I’m trying to get across is to use the power of Forms in the way it handles the transactions. Whilst we moan about it, it is actually quite good at that!
I hope this posting is taken in a positive light, I am certainly not trying to teach anyone to “suck eggs”.
PS. I find it ironic that you were prevented from coding DML statements outside of commit time triggers, in Forms 2.3!

Answer 1

Thank you, Kevin. Very informative.