asp.net - How to stop unwanted postback

Question

I work on ASP.NET C#. Under button click event I want to save something it's work fine, but after press the refresh button of browser, this event occurs again I want to stop this event.

Answer 1

An article on this subject.

Preventing Duplicate Record Insertion on Page Refresh

Approach 1

A simple solution is to Response.Redirect back to the same page after the INSERT command is called. This will call up the page without transmitting any post headers to it. Using Request.Url.ToString() as the first parameter of Response.Redirect will cause both the URL and the page's querystring to be included in the redirect. The use of false as the second parameter will suppress the automatic Response.End that may otherwise generate a ThreadAbortedException. A disadvantage of this approach is that any ViewState that had been built up will be lost.

Approach 2

A related approach would be for the form to submit to an intermediate processing page and then Response.Redirect back to the calling page, similar to the classic ASP approach to form processing. This has the same effect as simply using the Response.Redirect in the Button_Click event so it has the same disadvantages, with the added disadvantage of creating another page for the website developer to manage.

Approach 3

The next batch of solutions works by determining whether the user has refreshed the page in the browser instead of pressing the form's submit button. All of these solutions depend on the ability of the website to use Session variables successfully. If the website uses cookie-based Sessions, but the user's browser does not permit the use of cookies, these solutions would all fail. Additionally, should the Session expire these solutions would also fail.

Approach 4

Should the user somehow manage to circumvent the above mentioned solutions described above, the last line of defense is at the database. There are two methods that can be employed to prevent a duplicate record from being inserted into the database. For each method, I've moved the SQL code into a stored procedure, since there are now more processing steps involved and these are easier to illustrate in a separate stored procedure. Note however that a stored procedure is not strictly required in order for these methods to work.