Simple but interesting problem.

Hi all !

I am writing a blog application. In that on one page, I am showing the detailed post with its comments, alongwith a comment posting form. Now after posting the comment, if user presses the refresh button of the browser, the comment is posted and gets added to the database. How to slove this issue. I have looked at Microsoft's starter kits, but they also suffer from the same problem.

Thanks in advance.

Where did you place your database update logic? Can you post the code for the update logic? You shouldn't have that problem if you tie the database update logic to an event of a specific button. Say yo add a button called "btnPost" to your web page. You should use the "btnPost.OnClick" event to execute your database code.

I could give you a more specific example if I knew where your update code is presently.

After you handled the initial adding of the comment to the database useResponse.Redirect() to redirect the user back to the page. This process will clear all of the form input and will solve the refresh issue.

Hi,

I am agree with the both the solutions. This is very common problem if you have written your save logic in Page_Load event. And might be you are not clearing your textbox and other controls after saving the data.

Regards.

Best Practice would be to use a button event to trigger the database save. If all the code is being written in the Page_Load, you will run into many complications as your application grows. Take advantage of DotNets event triggers. It will keep your code more functional.

rstepan:

Best Practice would be to use a button event to trigger the database save. If all the code is being written in the Page_Load, you will run into many complications as your application grows. Take advantage of DotNets event triggers. It will keep your code more functional.

Simply handling the OnClick event for a button alone does not resolve this situation. When you click on a button in this situation the form is posted to the server. If you then refresh the browser after the button click, your browser will attempt to re-post the form. Events should be handled in event handlers, but that is not the focus here and in fact this problem still happens even when you use proper event handling. You need to use Response.Redirect in your event handler.

That is a simple solution that should work in his case. But, the disadvantage of that approach is that any ViewState that had been built up will be lost. And he may want that information.

The real trouble spot is on the database side. The database table is allowing for duplicates.

Another choice would be for him to change his stored procedure to check for existance of the record before doing the insert (i.e. IF EXISTS (SELECT * FROM table) ELSE INSERT INTO Table):

EXMPLE:

CREATE PROCEDURE spAddEmployee_UsingExists( @.FirstNamevarchar(50), @.LastNamevarchar(50))ASDECLARE @.ResultintBEGIN TRANSACTIONIFEXISTS(SELECTNULLFROM EmployeesWITH (UPDLOCK)WHERE FirstName = @.FirstNameAND LastName = @.LastName)BEGIN SELECT @.Result = -1ENDELSE BEGIN INSERT INTO Employees ( FirstName, LastName )VALUES ( @.FirstName, @.LastName )SELECT @.Result =@.@.ERRORENDIF @.Result <> 0BEGIN ROLLBACK ENDELSE BEGIN COMMIT ENDRETURN @.Result

Here's a link of all the possibilities you might care to try:

http://aspalliance.com/687#Page1

This is the best reply. This problem has nothing to do with asp.net and database. I searched more for this and found this link :

http://www.ervacon.com/products/swf/tips/tip4.html

All of these are hacks to get around your application's inability to control its environment (ie the browser's refresh button). Any application that wants to be commercial grade should be able to handle its environment. The solution for your application to do this is within the sql code it executes. If a table does not maintain a Primary Key to protect it from duplicates then the sql code that interacts with it should be made smart enough to handle the existance of duplicates and report back to your application where it can properly handle the case.

By redirecting back to your application, how does the user know his post was submitted? If he thinks he should have received a message and he didn't, he just might try to submit the same post again. And in that case, without the proper SQL code, you don't have any control over the user entering the duplicate message.

Regardless of the best way to handle the double postback issue you should always promote and enforce good database designs by using and enforcing keys and constraints. That being said, there is no silver bullet and all form posts do not always get saved to a database (i.e. Contact Us -> sends email). You should never redirect the user if an exception occurred that they should be made aware of. In that case you do not redirect, but instead display a friendly error and allow them to change input or attempt the post again. If the post was successful then you can redirect and you will be responsible for making sure that the user knows that their post was successful or maintaining view state. When I say post, I mean a postback to the server like sending an email or posting a comment to a blog. There are always exceptions, but most of the time, like in a blog for example, you perform data binding based on a query string, then if a user posts comments you save the comment to the database, and if successfully saved you can safely redirect and allow the page to perform the default data binding using the query string as the first request did. In that scenario the user would obviously see his post and know that his submission was successful and if there was an error it should have been reported to the user and no redirect should occur in that scenario. I know there are exceptions to this rule, but this pattern has worked very well for me in many different types of applications. I will note that when using the AJAX UpdatePanel I do change how I handle this situation, but that is a different model.

Maintaining a simple viewstate value will help remedy this problem, as the page is posting back. And we dont need to query the database too.