| Post built-in commits changes in the database [message #454840] |
Fri, 07 May 2010 12:51  |
quigs
Messages: 10
Registered: October 2007
|
Junior Member |
|
|
Hi All,
I have been testing out a form using 10.1.2.0.2 on a v10.2.0.1 db and in my local env. the form works correctly i.e. if I make a change and 'post' it and then exit and press NO (when asked to save changes) then it correctly leaves the value in the database as it originally was.
The process works by the user pressing a button in form A (read only form) and this opens form B (using open_mode,session,activate) and the user makes their change(s) in form B (a 'post' command is issued in a When New Rec Inst trigger on a db block when the user navigates to a new record within the same block if it is determined that the block status <> 'QUERY') before returning to form A and pressing 'NO' when prompted to save changes.
However, if I run the same process in the TEST env. using the same executable against the same database then it actually updates the database value.
I have tested this by adding a debug message at the end of form B to retrieve the db value back AFTER having issued a clear_form(no_commit) just for the sake of the test and it still returns me the 'new' i.e. amended value - which is obviously incorrect.
From what I can see it would appear that the commit occurs straight after the 'post' has been issued and well before the user even exits the form.
Is this a known bug with the 'post' built-in or could it be that a parameter is set to act in this way (i.e. is there an 'autocommit' setting that is 'ON') within the application server?
I would appreciate an urgent response as I am due to deploy the form in the production env. very soon.
Kind regards,
Tom
|
|
|
|
|
|
| Re: Post built-in commits changes in the database [message #454844 is a reply to message #454843] |
Fri, 07 May 2010 13:08  |
quigs
Messages: 10
Registered: October 2007
|
Junior Member |
|
|
Hi,
Thanks for your reply.
I have checked it via TOAD and it shows the db value changed after exiting form B and returning to form A. However I know that with debug messages in Forms itself that the value has already been changed and committed before form B is exited as I use a select statement against the db (within the form) after the clear_form(no_commit) command before the exit_form statement.
Kind regards,
Tom
|
|
|
|
| Re: Post built-in commits changes in the database [message #454867 is a reply to message #454844] |
Fri, 07 May 2010 19:03 |
cookiemonster
Messages: 13963
Registered: September 2008
Location: Rainy Manchester
|
Senior Member |
|
|
|
That doesn't necessarily prove anything, by default clear_form rolls back to the last savepoint, where as exit_form rolls back every change made in the form. The only way to know for sure when the data is committed is to see when it becomes visible to another session like TOAD.
|
|
|
|
|
|
| Re: Post built-in commits changes in the database [message #455146 is a reply to message #455059] |
Mon, 10 May 2010 08:33 |
quigs
Messages: 10
Registered: October 2007
|
Junior Member |
|
|
Hi David,
Thanks for your reply.
I don't believe there to be anything in place that would cause the issue (as you've outlined) but would need a further check.
Looking into it further, I even removed all of the logic that is within the WNRI trigger on the block in question apart from the 'post' statement and the process still incorrectly saves the change when not asked to do so.
I then changed form A to call form B via call_form (rather than open_form) and found that although the record didn't save, it caused other issues to appear.
My solution is to call form B from form A in open_form 'NO_SESSION' parameter mode and this has allowed the process to work correctly.
Additionally, realising that the 'No changes to apply' and 'Calling form has unsaved changes' messages were being generated by the source form A have handled them as well.
Subject to the user saying that testing has been successful then I'll leave things as that.
The question I have is why is there an implicit commit applied with the open_form in SESSION mode - regardless of what actions you take. Is it a bug in forms internal processing?
Kind regards,
Tom
|
|
|
|
|
|
|
|
| Re: Post built-in commits changes in the database [message #455465 is a reply to message #455276] |
Tue, 11 May 2010 12:16 |
quigs
Messages: 10
Registered: October 2007
|
Junior Member |
|
|
Hi David,
Thanks for your update.
As the parent form is a data retrieval form only and there are no commits within it (the user can't make any actual changes in the form) then I would think that the OPEN_FORM no_session mode should be ok but I take on board what you've said.
Kind regards,
Tom
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
