Additional Query
July 2, 2002 - 10am Central time zone
Reviewer: Barathi A C from India
what is the purpose of using 'Forms_DDL('Commit')?
This way of commiting creates problems in concurrent access?
Pls throw a light on this..
Followup July 2, 2002 - 12pm Central time zone:
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 "
July 3, 2002 - 12am Central time zone
Reviewer: A reader
can you please elaborate...
Followup July 3, 2002 - 6am Central time zone:
COMMIT_FORM;
July 7, 2002 - 3am Central time zone
Reviewer: Barathi A C from India
Thanx a lot Tom!
Why this doesn't works ?
July 16, 2002 - 5am Central time zone
Reviewer: Riaz Shahid from PRAL,Islamabad,Pakistan
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 ?
Followup July 16, 2002 - 7am Central time zone:
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
July 16, 2002 - 1pm Central time zone
Reviewer: Thx
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.
Followup July 16, 2002 - 5pm Central time zone:
"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
October 29, 2002 - 8am Central time zone
Reviewer: praora from India
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.
Followup October 29, 2002 - 1pm Central time zone:
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
October 30, 2002 - 10pm Central time zone
Reviewer: Srikant from India
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
Followup October 31, 2002 - 8pm Central time zone:
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
October 31, 2002 - 6am Central time zone
Reviewer: Praora from India
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.
Followup October 31, 2002 - 8pm Central time zone:
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
October 31, 2002 - 11pm Central time zone
Reviewer: praora from India
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
Followup November 1, 2002 - 6am Central time zone:
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
November 1, 2002 - 2am Central time zone
Reviewer: praora from india
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.
|