At 03:26 PM 06/13/2002, Mark Stosberg wrote: >On Thu, 13 Jun 2002, Juan Jose Natera Abreu wrote: >>I guess most of you have experienced the problem of "duplicated >>submissions due reload button" I have seen some protections against >>it on the web, and I would like to implement it on my apps. >> >>My first thought is to compare the values being submitted with >>those in the database, if they are exactly the same then abort the >>action... > >In the case where the form is being used to insert some data into a >database, here's an easy trick that I like to use: > >In the form display run mode, select the next available unique ID >for the item that will be it's primay key. When you submit the form, >you simply have to check to see if you've already inserted something >with the same ID (which your database may actually prevent you from >doing anyway).
One problem with doing this is that if a second user pulls up the same form immediately after the first user pulled up the form, you now have two users with the same "key" in their form. Whichever one submits first will "win", and the other's will be rejected. Depending on how you handle the rejection, the user either won't know it didn't succeed, or will know but will have to get a new form and fill it in again. Another problem is that this will prevent the user from backing up to the form after it was submitted, changing the values slightly, and submitting again for a slightly different entry, which should still be unique. There may be cases where this is acceptable, and yours may be one of them, but it's something to keep in mind. Another way to handle this is to have a two-part submission. The first form creates a recrod in the database, but somehow marks it as unconfirmed. You then return a confirmation form with the key for that record. You can even include the form data on the page for the user to verify. A form on this page will then confirm the entry. This makes it nearly impossible to get unintentional duplicate entries. If the user reloads the first confirmation page, they will create a new entry, but it will be unconfirmed, and so will require an additional action to confirm. A reload of the second confirmation page will at worst simply reconfirm the first entry. This will require some additional maintenance as unconfirmed entries will have to be cleared out after some timeout period. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning" --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
