I had a problem with a modal dialog page in APEX 5.1, which created new rows in a table on the database whenever the Create button was pressed. The problem was that if the user was very quick i.e. double/triple clicking on the Create button, then it was possible to create duplicate rows on the database with exactly the same data.
In APEX 5.1, you have a few options available in the page attributes that concern how to handle a page submission. Namely:
My page was set to the default options for these attributes in a new APEX 5.1 modal dialog page; Enable Duplicate Page submissions was set to ‘Yes’ and Reload on Submit was set to ‘Only for Success’.
Excellent I thought, all I need to do here is change Enable Duplicate Page submissions to ‘No – Prevent page from being re-posted’ and my problem would be solved!
However, I hit a problem. Because all of the validations on the page were custom server side validations which occur after the submit; if any of them failed then it would no longer be possible for the user to submit the page at all, even if they corrected all validation errors, and they would be presented with:
Had all the page validations been client side (i.e. the ones that appear on the item attributes like ‘Value Required’ or ‘Subtype’) then this wouldn’t have been a problem as all of these validations occur client side before the ‘submit’. Please see my colleague Matt Mulvaney’s blog here for a full description of Client Side Validations.
However, as the page has a number of dynamically displayed items and other required custom validations to do with the dataset I require some more advanced server side validations written in PL/SQL on my page.
Let us look at the new option for APEX 5.1; Reload on Submit. What this does when set to ‘Only on Success’ is handle the server side validations in a much nicer way so that the page doesn’t completely reload on submit when validation errors occur and instead the validations look like they behave how they do with client side validations and the errors are displayed without the page re-loading.
This is much nicer than in 5.0.x versions of APEX and greatly improves the user experience and performance of a page so I really want to keep this behaviour!
So the next thing I did, to try and stop the duplicate page submissions, was set Enable Duplicate Page submissions back to ‘Yes’ and applied a different fix Explorer commonly use to stop duplicate page submissions. On the button used to submit the page, we add a dynamic action, which fires on the click of the button, which has a JavaScript action of disabling the button (to stop the user pressing it again) and then submitting the page:
(Don’t forget to give your button a static ID. I called mine CREATE_BUTTON).
Great, let’s give that a try (and deliberatley cause some of my server side validations to fire):
Darn! the button is disabled but I need to press it again after correcting my validation errors, what’s caused this? Well, it’s that option I just talked about: ‘Reload on Submit’. Because this is set to ‘Only for success’ the page hasn’t reloaded after validation errors and my button is still disabled.
So in order to use my fix to stop the button from being pressed twice I need to set this back to ‘Always’ and lose the niceness of the way server side validations are handled in APEX 5.1.
So, for the moment* if you have page where you want to detect or handle duplicate page submissions you have the following options:
*Oracle have acknowledged that this behvaiour is a bug, see here. So hopefully in APEX 5.2 we will be able to have the best of both worlds!
Author: Paul Jones
Job Title: Oracle APEX Development Consultant
Bio: Paul is a Development Consultant at DSP-Explorer. Paul has a BSc in Computing from the University of Leeds and is now building on considerable experience in development and support using Oracle PL/SQL and Oracle E-Business Suite (EBS). Paul is employing APEX to provide quality, bespoke software solutions both internally and to a range of organisations.