Is there any good way to ensure data is not entered into a mysql database table using a page refresh? I am building an application for a photographer that will be ran over an intranet that tracks sales, orders, payments and tasks to complete. I am at the invoice section. I want to ensure that if someone presses the refresh button data isn't inserted twice. The only problem I am having is a record could essentially contain all of the same data, and it wouldn't really be that rare. Ussually I would check a mysql record and ensure it wasn't a duplicate. In this case that will not work.

Btw it is nice to see an active forum, where people are actually here. All of the other web design forums I have stopped by seem to be really dead!

one thing you could do is input an ID number urself as a primary key rather than letting mysql generate it incrementing-ly. when you make the form where the user adds the info, you could find the highest number ID, add one to it, and put it as a hidden field. once they hit submit, all the info will be added plus that ID number. however, since it already had retrieved the highest id number when the form was generated, hitting refresh would send the same id number and you coul djust do a check to see if that id number already exists.

at least, i think that would work... give it a try.

Originally Posted by nasaboy007

one thing you could do is input an ID number urself as a primary key rather than letting mysql generate it incrementing-ly. when you make the form where the user adds the info, you could find the highest number ID, add one to it, and put it as a hidden field. once they hit submit, all the info will be added plus that ID number. however, since it already had retrieved the highest id number when the form was generated, hitting refresh would send the same id number and you coul djust do a check to see if that id number already exists.

at least, i think that would work... give it a try.

Excellent answer, but I cannot give you tp anymore. I have to spread some more before ;-)

Just one remark: don't use this key as a field in db.
Check the form hidden field against a session saved value.

like this:
1) user Tom access a page with a form. The PHP script add tho the form an hidden field which contains a random hashed value ( look at http://www.php.net/manual/en/function.uniqid.php ).
At the same time, save that hashed value into the session, like $_SESSION['formHash']
2) On the form processing, start by checking that there is an hidden hash value, and compare it to the session one.
If the values are identical, process the form. If not, redirect the user to an message page, telling him what happened.

One work less solution would be to integrate the generation/session saving of the hash value in a prepended php page. That way, another value would be generated on each page without you to have to think about it.
Just one warning: if you have ajax calls, this will modify the session hash behind the curtain, thus invalidating your currently displayed form.
Think to filter those ajax requests out.

If your inserting data from a web form from the previous page, you can just have a HTTPD header redirect to the same page after processing to destroy all the post data. If you have no post data, then you should not have any reason to write to the db and actions like refresh and back/forward will not resend post data.

What Mgraphic said is great
You can create a httpd redirect to redirect user.
You can do the following:
Page1: the form page, and this form send to Page2.
Page2: the form processing, then a header() function to Page3.
Page3: the final page,
So the user will be in page3, he can refresh with no problem
This is the easiest way I think, just a new file between your two files.

Yes, redirect is indeed a good option.
The advantage of the challenge in the form, is to prevent xss injection too.
You ensuer that the form you receive is coming from the one host who was designed to.

mgraphic I think I'll go with your idea, seems simple enough. I really don't have to worry about any security issues since it will only be a few people on the application and it will be ran locally rather than via the web.