POST built in - Umm, this is the worst and doesn't work as intended..

Question

Win XP, oracle 10gR2
POST really likes to save my changes.
I post a block, and then goto my next form.. and I use another session with another login to view the data and it has already been comitted.
This may have worked back in Client Server as intended , but it is surely lacking on the web forms.
My form forms coworker said I'll just go busting my brains out trying to get it work, and he never got it work either, and said post doesn't do what you think it is supposed to do.
He thinks we had problems with it even back on Client Server.
Can anyone else confirm?

Answer 1

Hello,
Very easy to test.
Create a basic form on the emp table, do some changes
then post.
Open another session with Sql*Plus or Sql Developer,
then check if you see the changes or not.
FrancoisI'll change my story to posting with "multiple forms" doesn't work.
Form A - I make changes and POST.
I call form B (the select form)
I then call form C (edit screen) and make a change.
I exit_form C, and say "NO" to forms asking me if I want to save changes.
I exit_form B (no prompt, no base table block).
In form A, I exit_form, and say "NO" to forms asking me if I want to save changes.
I reenter the form A, and the value is changed to the new value.
I just watched the column, and when I called form C - that's when the commit was performed. I see no commit's that were executed when calling for C.
I am trying to avoid a frm-40403 (calling form has unapplied changes).
Post isn't cutting it, so I plan to check the form_status and prompt the user if they want to commit (yes/no/cancel).."No" will cause an frm-40403 if they try to save in the form C. Of course if they say "yes" to commit, it will not have the problem in form C.
I just checked, and I don't think I have any commits in Form C - if I did - I wouldn't get an FRM-40403 when I try to save in Form C.