Forms 3.0.16 - Commit in a form called from another form
Anna Hedington
to the calling form, which needs sight of the changes for a Pro*C user
exit??
The calling form calls the new form and the user exit in a PRE-UPDATE
trigger. The new form is an enhancement to a well established form.
COMMIT in the called form produces 'FRM-40403: A calling form has unposted
changes. Commit not allowed'. Changing KEY-COMMIT to 'POST' and KEY-EXIT
to 'EXIT_FORM(NO_ROLLBACK)' in the called form produces encouraging
messages, ie 'n records posted' etc, but the changes appear to be lost
on return to the calling form.
Putting the CALL() and user exit within a POST-COMMIT trigger in the
calling form also does not work - the magic message 'FRM-40400:
Transaction complete -- 1 records posted and committed' appears after
my debug messages in POST-COMMIT.
Any thoughts welcome.
--------------------------------------------------------------------
Anna Hedington heding...@bt-web.bt.co.uk
ISEC Tel: +44 1473 227234
BT Bibb Way Fax: +44 1473 231727
--------------------------------------------------------------------
The opinions expressed here are my own and not my employer's.
Tommy Wareing
>
>Any ideas how I can commit changes in a called form before returning
>to the calling form, which needs sight of the changes for a Pro*C user
>exit??
Anything POSTed to the database before your user exit is called should be
visible to that user exit, since it shares the same Oracle session.
>
>The calling form calls the new form and the user exit in a PRE-UPDATE
>trigger. The new form is an enhancement to a well established form.
>
>COMMIT in the called form produces 'FRM-40403: A calling form has unposted
>changes. Commit not allowed'. Changing KEY-COMMIT to 'POST' and KEY-EXIT
>to 'EXIT_FORM(NO_ROLLBACK)' in the called form produces encouraging
>messages, ie 'n records posted' etc, but the changes appear to be lost
>on return to the calling form.
Try including a POST in the _calling_ form, just before the call statement.
The second form should then not need any special treatment: it shouldn't care
whether it's running stand-alone, or called from another form (as in this
case). You may see a slight difference in the messages, but that's all.
--
_________________________ __________________________________________
/ Tommy Wareing \ / I've been looking for an original sin, \
| p007...@brookes.ac.uk X One with a twist and a bit of a spin |
\ 0865-483389 / \ -- Pandora's Box, Jim Steinman /
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stephen Turner
>>The calling form calls the new form and the user exit in a PRE-UPDATE
>>trigger. The new form is an enhancement to a well established form.
>>
>Try including a POST in the _calling_ form, just before the call statement.
>The second form should then not need any special treatment: it shouldn't care
>whether it's running stand-alone, or called from another form (as in this
>case). You may see a slight difference in the messages, but that's all.
I was going to post (if you'll pardon the expression) the same solution,
but I remembered that you can't POST in a PRE-UPDATE trigger, POST being
a restricted packaged procedure. Maybe this would be the right solution in
the long term, but the call to the other form would have to take place
elsewhere.
Steve Turner