Additional Query
Barathi A C, July 02, 2002 - 10:11 am UTC
what is the purpose of using 'Forms_DDL('Commit')?
This way of commiting creates problems in concurrent access?
Pls throw a light on this..
July 02, 2002 - 12:52 pm UTC
It commits in the database (the transaction is over) but Forms did not know about it. Hence, forms will think all data that was POSTED to the db is still posted but not yet committed. Also, all changed data that forms BELIEVES is locked will no longer be locked.
It is a bad idea to use forms_ddl to commit like that. Use the forms methods so everything works nicely.
what do you mean by "forms methods "
A reader, July 03, 2002 - 12:14 am UTC
can you please elaborate...
July 03, 2002 - 6:58 am UTC
COMMIT_FORM;
Barathi A C, July 07, 2002 - 3:25 am UTC
Thanx a lot Tom!
Why this doesn't works ?
Riaz Shahid, July 16, 2002 - 5:07 am UTC
Hello Tom !
I have a procedure in form like:
procedure aa is
begin
update mytab set flag='Y'
where claim_no=:myblock.claim_no;
end;
But when i see that in MyTab, the flag is not updated...why it is so? The flag is updated only when i leave the form and then re-enter. What is the cause for that...I want flag to be updated immediately. Do i need a database trigger or procedure for that ?
July 16, 2002 - 7:36 am UTC
If you are looking at MYTAB from another session using sqlplus for example -- you won't see the changes until you COMMIT in your form. Other sessions cannot see uncommited work
commit and commit_form
Thx, July 16, 2002 - 1:19 pm UTC
Tom
when I code a client side procedure in my forms. Do I have to include an explicit commit or commot_form inthe procedure(as I'm updating and deleting using this procedure), or do I have to commit the form using the menu.
If I use commit in my client side procedure does it have any side effects.
What is the diff between commit and commit_form.
July 16, 2002 - 5:52 pm UTC
"have to" -- no
"should" -- insufficient data.
Do you want your END USER to be in control of the transaction? If so - answer = no.
If you want your CODE to end the transaction -- answer = commit_form (so forms will POST any other changes and then commit). If you just "commit", you might not post changes that forms did. See the first followup -- we talk about it there.
Same session update not happening
praora, October 29, 2002 - 8:54 am UTC
I have a database procedure called by forms which also has a cursor with a for update of ... nowait clause. Inside the procedure I am updating one column of one table(out of three) using the where current of clause of the update statement. I am spooling the results on to a txt file using utl_file for debugging.
Now though there is a commit_form issued, the records get updated only when the user exists out of the form and re-enter it again.But if he proceeds ahead with the same transaction the updates are not committed.
October 29, 2002 - 1:46 pm UTC
commit_form only does something if you CHANGED DATA IN FORMS, using forms.
you called a procedure, forms is totally unaware there are outstanding modifications
You should use:
POST_FORM;
commit;
instead when you do some updates via forms and some "by yourself"
Open_Form in Separate Session
Srikant, October 30, 2002 - 10:52 pm UTC
Hi Tom,
In my application to avoid the above said problem when users work simulatenously with multiple forms, I am using Open_Form with SESSION, so that each form is opened in a separate session and I won't have any problem while commiting one form. My doubts are: -
1. If I am opening each form in a separate session, will that affect the performance in any way. Do you prefer this? If not, what is the work around?
2. I have a library that is attached to all the forms and the library has a package. The main idea was to share the package variables across the application in all the forms. But since I am opening each form in a separate session, each form will have a separate copy of the Library (Please correct me if I am wrong) and hence I am not able to access the value across the forms. Is there any work around for this other than using Global variables? What do you suggest.
Kindly advice. Thanks.
Srikant
October 31, 2002 - 8:53 pm UTC
1) i don't like it -- you are opening a SESSION (eg: consuming lots of extra resources). I personally haven't seen an application that needs more then one -- very very rarely TWO sessions.
I cannot imagine why in a forms application (heads down data entry stuff) you need more then one transaction going -- I'd really need to know much more about WHY the you believe the application needs this sort of complexity. As an end User I would be seriously wondering why my changes on one screen could never be visible on another until i committed them. Just not natural.
There may well be a good reason you need to, I just cannot imagine it yet.
2) sounds right -- you are in different sessions totally, different states, no sharing for you.
My problem not understood clearly
Praora, October 31, 2002 - 6:19 am UTC
Mr. Tom,
Following my earlier posting, the suggestion you made helped a bit but did not solve my prob.
I have trn 1 : Some updations in form. A call to a database procedure that does some updations in the backend. User commits. Clears the form. In the same session,
trn 2: A similar transaction like trn 1. Commits , clears the form again in the same session.
Now after trn 2 he exits the form.
If I see the database all changes due to trn 1 and trn 2 made in the form are committed. But changes made by the database procedure for trn 2 are only committed.
I tried post; call procedure; commit;
No change.
So i put a commit inside my database procedure . No change.
I am banging my head for the past 2 weeks . Please help.
October 31, 2002 - 8:56 pm UTC
Sorry, I'll be blunt -- but I "don't believe what you say is happening happens"
You would have to tell me step by step by step how to reproduce this. If exiting the form makes the "data suddenly appear", the above steps you describe are not physically possible.
Please tell me if the info below suffices
praora, October 31, 2002 - 11:57 pm UTC
Mr. Tom,
As requested by you here are the steps I have in the form.
This is a master detail form. I need to do updates to other tables when a specific column in the base table of the detail block is updated. I have a before update (row level) trigger which updates a package. I use this package in my procedure to update the other tables. This is the situation.
The steps taken by me earlier are: I have verified the package which has a plsql table. The package gets filled up fine through my before update trigger.
In the procedure(under discussion) I have a cursor with a for update of a specific column with a nowait clause. The table (under discussion) is updated using the where current of clause.In the process of debugging at one point I removed the for update clause and used the primary key columns to update the table .I used the returning clause on this update statment and spooled the results to a log file. I found that the update statement did not fail as the returning clause gave me the correct value.But even then only the last transaction values got committed. So I reverted to the earlier situation,and here I stand.
The business flow and the pk , fk etc could not be explained here as it would be complicated.
Thanks in advance
November 01, 2002 - 6:37 am UTC
and how are you committing? commit_form or forms_ddl('commit') or commit; in plsql.
I believe you are using commit_form, the form had nothing to commit in fact and hence did not commit and therefore your changes are not "visible" until after you exit then form which ends your transaction and commits for you.
It is something else
praora, November 01, 2002 - 2:28 am UTC
Mr. Tom,
I just believed what you said and started my debugging in a different fashion. The problem is different.
I have solved it.
Thanks a lot.
I will not need any reply for my ealier post.