Re: Disabling Commit and Update

#1

Jim wrote:

Quote:

Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

You don't explain what means are currently available to users. Or what
version. Or much else. So I could offer ideas but they wouldn't
necessarily be meaningful.

What I would like to dispute is the statement that some calculations are
too complex for trigger: Nonsense!

Write the code as a stored procedure, either in the database or the form,
and execute it from the trigger.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

#2

Hi Jim, thanks for writing this:

Quote:

Hello,

<snip>

Quote:

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

In the "old days" (and since I haven't used Forms lately, I don't know
if it's still the case), I used Oracle Terminal to specify what
"action" a particular key performed. For example, using Oracle Terminal,
I was able to "map" the F6 key to a "commit" action. I could also
"unmap" the F6 key so it no longer performed any action.

By the way, what version of Forms ARE you using?
--
[:%s/Karsten Farrell/Oracle DBA/g]

#3

"Jim" <jim_esti (AT) hotmail (DOT) com> wrote

Quote:

Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

key-commit, key-updrec triggers which will do nothing (null

tool bar ? can't remember what cathes those ones,
hopefully the same triggers.
Is this homework, if I my ask ?
If you are able to try it out from a home pc, then download the
software from otn.oracle.com (read the license conditions!)

#4

"Jim" <jim_esti (AT) hotmail (DOT) com> wrote

Quote:

Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

Not sure I understand your problem. What functionality can you put in you
WHEN-BUTTON-PRESSED trigger that you think you can;t put in the standard
KEY-COMMIT trigger then?

The work should all be in packages and procedures and then called from
anywhere necessary, i.e. both triggers mentioned above.

If it's simply a required to 'disable' the commit key then define the
KEY-COMMIT trigger to do nothing. Assuming your using a standardmenu it
will effectively disable that too. Better still, remove the commit option
from the menu as well.

The other thing that occurs to me is that standard commit processing is not
required by you because you are trying to bypass it by placing DML code
directly into your WBP trigger. Although this works, it is not normally
recommended and you asre advised to rethink your strategy (if this is what
you're doing) to use the standard commit phase triggers for you DML.

#5

I am using Forms 5.

I have have disabled the key-commit feature via a trigger.

The issue remains that say a user re-queries or does some other action
the form often ask if they would like to save the changes. I never
want to allow the user a chance to save the changes by any onther
means than the POST button provided.

Here is exactly what I am doing.
The user queries the table and then they can change selected values in
the some columns. When they hit the post button it only looks at row
that have changed and copies those into AUDIT if certian conditions
are meet. If the conditions are not meet the row is rejected is
reverted back to the orginal values while the other rows are updated
on the primary table (and a copy is dropped into an audit table).
The only way a row can be updated is if these certian conditions are
reached. It works on a row by row case - not the entire table at once.
This is why I can not have a general update or commit of the entire
table. The post button processes only the rows that have changed from
the orginal and if the new values is valid then it just updates that
particualr row and places a copy in the audit table. Warnings are
giving about the particular row(s) that can not be updated/audited.

This is significantly different than just writting a simple on-update
or on commit trigger. I know I could simiply could put the code
behind the on-update, on-commit, etc but I would rather just diable
those possiblites and only allow the changes to occur via the post
button.

"kn" <keldn (AT) kill (DOT) spam> wrote

Quote:

"Jim" <jim_esti (AT) hotmail (DOT) com> wrote in message
news:f0e3dc0b.0307211014.3b7ee8f1 (AT) posting (DOT) google.com...
Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

key-commit, key-updrec triggers which will do nothing (null

tool bar ? can't remember what cathes those ones,
hopefully the same triggers.
Is this homework, if I my ask ?
If you are able to try it out from a home pc, then download the
software from otn.oracle.com (read the license conditions!)

#6

I'll forego comment on the sensibility of what you're doing, as I'm sure
others will comment, and just offer you a very simple method to accomplish
what you're asking: use a global variable to "flag" the commit (or pre-commit)
trigger... set it to "true" before committing, and have the trigger set it
back to "false."

In article <f0e3dc0b.0307211014.3b7ee8f1 (AT) posting (DOT) google.com>,
jim_esti (AT) hotmail (DOT) com (Jim) wrote:

Quote:

Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

#7

Alternatively, just put null (or any disabling logic you require) in the
key-commit trigger. Although mentioned in the documentation, I have never
found OT in my Developer 6i install.

In article <MPG.1985fb0656f332309897f4 (AT) news (DOT) la.sbcglobal.net>, Karsten Farrell
<kfarrell (AT) belgariad (DOT) com> wrote:

Quote:

Hi Jim, thanks for writing this:
Hello,

snip

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

In the "old days" (and since I haven't used Forms lately, I don't know
if it's still the case), I used Oracle Terminal to specify what
"action" a particular key performed. For example, using Oracle Terminal,
I was able to "map" the F6 key to a "commit" action. I could also
"unmap" the F6 key so it no longer performed any action.

By the way, what version of Forms ARE you using?

#8

In article <f0e3dc0b.0307220439.5d4dd7d0 (AT) posting (DOT) google.com>, jim_esti (AT) hotmail (DOT) com (Jim) wrote:

Quote:

Here is exactly what I am doing.
The user queries the table and then they can change selected values in
the some columns. When they hit the post button it only looks at row
that have changed and copies those into AUDIT if certian conditions
are meet. If the conditions are not meet the row is rejected is
reverted back to the orginal values while the other rows are updated
on the primary table (and a copy is dropped into an audit table).
The only way a row can be updated is if these certian conditions are
reached. It works on a row by row case - not the entire table at once.
This is why I can not have a general update or commit of the entire
table. The post button processes only the rows that have changed from
the orginal and if the new values is valid then it just updates that
particualr row and places a copy in the audit table. Warnings are
giving about the particular row(s) that can not be updated/audited.

Seems to me that this could largely be accomplished via database triggers
without substantially altering Forms' default behavior... and probably
requires less coding.

#9

In article <f0e3dc0b.0307221347.daccc20 (AT) posting (DOT) google.com>, jim_esti (AT) hotmail (DOT) com (Jim) wrote:

Quote:

As I said I could put the code in the various aspects. As you
indicated that it would be ideal to have a simple procedure to handle
the process and I agree.

But it is not indicated that way in my specs.
The specs indicate that all forms of COMMIT, UPDATE etc be removed and
only the possible way to do any sort of commit, update etc would be
through a POST button.

The problem becomes when I null out the KEY-COMMIT or ON-UPDATE
trigger and then call for a commit in the POST button it fails. It
appears that the trigger catchs the commit. It must be due to the
methods used in the button to do the actions.

I have resorted to added:
:global.trigger_disable := 'true'; -- added to the start of the POST
Button
:global.trigger_disable := 'false'; -- added to the end of the POST
Button

Then in the KEY-COMMIT, ON-UPDATE etc I added:

if if :global.commit_disable = 'false' then
message ('Commit not allowed here.');
else
commit;
end;

The tricky part comes when I do the on-update trigger.
This simple trick will not work as easily as I update each row
seperately and update different columns based upon special cases. The
joy fun of it.

I'm missing something... how does the on-update trigger ever get fired without
a pre-commit trigger being fired first? Try moving your disable logic to the
pre-commit trigger.

#10

"Jim" <jim_esti (AT) hotmail (DOT) com> wrote

Quote:

Hello,

I have a basic form and a post button.
The user is able to view and query a particular table.

When the user presses the post button some calculations are done and
the table they where looking at is updated via the post button only.
The calculations and features behind the post button are to
specialized and complex to do via update trigger or commit trigger.

I can write the post button so that it updates the table correctly.
What I want to do is disable the user's ability to Commit and Update
that table via another means than that post button. When I try to add
triggers to the block the Commit and Updates it effects the updates
and commits I do on the POST button.

How can one disable the Commit and Update keys/process and yet be able
to do the same functionality on a button? The only way I want to let
the user Commit or update is via this post button.

Any Ideas?

Having more thoughts on this....

I'm still not sure why you need to disable the KEY-COMMIT function key.
Presumably, your button contains a simple call to COMMIT_FORM to do your
changes. As such, how and why is the processing different to pressing the
commit function key?

If there is any other code in your button press, i.e. some processing either
side of the call to COMMIT_FORM then you are in trouble for another reason.

Any attempt to clear a block or the form when changes are made (in the local
block of course) will result in a 'Do you want to commit your changes'
question. Hitting yes to this will bypass your button press completely,
effectively calling COMMIT_FORM directly.

How have you got around this problem? Just another reason to make sure you
use standard commit processing sequences and triggers.