FORMS_DDL('rollback') - does it makes sense?
Rolf Unger
I want to do a rollback of my
update table_b set col_a=2 where col_b = :BLOCK_A.col_b;
that I have executed in a "WHEN-BUTTON-PRESSED" trigger.
If I simply do the natural approach and use a "ROLLBACK"
inside the trigger code, FORMS converts it to the built-in
"Clear_Form" and all my blocks are empty.
That's not what I want!
I googled on this issue, and found that some people recommend
to use the Forms package FORMS_DDL for that. The examples that
were used in those topics are all relating to a commit
but not to a rollback.
I looked in the online help documentation and I found the following
note:
,---------------------
: FORMS_DDL built-in
:
: Usage Notes:
: Commit (or roll back) all pending changes before you issue
: the FORMS_DDL command. All DDL operations issue an implicit
: COMMIT and will end the current transaction without allowing
: Form Builder to process any pending changes, as well as losing
: any locks Form Builder may have acquired.
:
'----------------------
I'm not sure, what "All DLL operations" should mean.
Does it mean:
a) "All calls to "FORMS_DDL" issue an internal commit!"
In that case a forms_ddl('rollback') will actually do
a commit (the internal one) and then the rollback that
is passed as string parameter. Of course this makes it
useless!
b) "The internal commit is only executed if the string parameter
passed to FORMS_DDL contains a DDL statement
(e.g. 'truncate table a_table')"
Despite from that it is basic SQL wisdom and related to any
Database tools, that would mean that a 'delete from a_table'
as parameter would not do a commit.
So my forms_ddl('rollback') would only issue a rollback as
instructed do without any internal commits before or after.
I'm happy about any comments. (Well, nearly every one :-)
Rolf.
Tiago Rocha
>Hi,
>
>I want to do a rollback of my
>
> update table_b set col_a=2 where col_b = :BLOCK_A.col_b;
>
>that I have executed in a "WHEN-BUTTON-PRESSED" trigger.
>
>If I simply do the natural approach and use a "ROLLBACK"
>inside the trigger code, FORMS converts it to the built-in
>"Clear_Form" and all my blocks are empty.
>That's not what I want!
You can tell forms that these records aren't new, so forms won't issue an "insert" or "update".
Set_Record_Property( block_name, 'QUERY_STATUS' ) will do this.
hth
--
Tiago Rocha
Recife - Brasil
www.diariodastrilhas.cjb.net
Rolf Unger
Hm,
I guess I was not clear enough. Forms doesn't know anything about the
update. It is processed in the background on the database. The button
trigger that I am refering to is a simple push button, that has no
relation to a database block.
I'm pretty sure that I haven't changed any block items when I issue the
"rollback;" in the trigger, so the status of the block or the system
should be 'QUERY_STATUS' already (or still).
What I did to keep Forms from clearing all my blocks is to use a stored
database package:
CREATE OR REPLACE PACKAGE hidden
AS
PROCEDURE do_rollback;
END;
CREATE OR REPLACE PACKAGE BODY hidden
AS
PROCEDURE do_rollback
IS
BEGIN
ROLLBACK;
END;
END;
And instead of putting a straight
rollback;
in my trigger code, i do:
hidden.do_rollback;
... and it does what I need.
Still, it's one more point that makes me think:
"If I need to work with such sick workarounds, I should maybe
decide that this tool has too many limitations. Time to code
everything in Java!"
Rolf.