Avoid inserting a duplicate record on page submit?

[planetthoughtful]

Hi All,

I have a C# ASP.NET page that submits back to itself to insert details
from a form into a database table. When / if the user refreshes the
page (and gets the standard warning that POST data will be
resubmitted), the previously submitted record is sumbitted again, and a
duplicate record is inserted into the table.

In PHP I would have avoided this by submitting the form to a processing
page, which would then automatically redirect back to the form page to
display success, etc. So, it would look something like this in PHP:

dataentry.php --> processdataentry.php --> dataentry.php

Doing this would avoid a duplicate record being inserted if
dataentry.php was refreshed.

I'm wondering how the same issue is handled in C# in ASP.NET? Do you
essentially do the same thing? ie submit the form to a processing .aspx
file and then redirect back to the dataentry page? Or is there a way of
avoiding duplicate insertions (aside from setting up unique indexes on
the underlying table - unfortunately, duplicates *are* at times
legitimate, so I can't assume that the existence of any duplicate means
that the page was incorrectly refreshed) while still posting back to
the same page?

Any help appreciated!!

Much warmth,

planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org

[Dale]

As if I haven't been in enough trouble lately, let me assert that the best
way to keep from having a duplicated row in your database is by the use of a
proper natural primary key.

You can join in on the fight by reading my blog at
http://www.dalepreston.com/Blog/2005...ty-crisis.html.

HTH,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA
"planetthoughtful" wrote:

Hi All,

I have a C# ASP.NET page that submits back to itself to insert details
from a form into a database table. When / if the user refreshes the
page (and gets the standard warning that POST data will be
resubmitted), the previously submitted record is sumbitted again, and a
duplicate record is inserted into the table.

In PHP I would have avoided this by submitting the form to a processing
page, which would then automatically redirect back to the form page to
display success, etc. So, it would look something like this in PHP:

dataentry.php --> processdataentry.php --> dataentry.php

Doing this would avoid a duplicate record being inserted if
dataentry.php was refreshed.

I'm wondering how the same issue is handled in C# in ASP.NET? Do you
essentially do the same thing? ie submit the form to a processing .aspx
file and then redirect back to the dataentry page? Or is there a way of
avoiding duplicate insertions (aside from setting up unique indexes on
the underlying table - unfortunately, duplicates *are* at times
legitimate, so I can't assume that the existence of any duplicate means
that the page was incorrectly refreshed) while still posting back to
the same page?

Any help appreciated!!

Much warmth,

planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org

[planetthoughtful]

Dale wrote:

As if I haven't been in enough trouble lately, let me assert that the best
way to keep from having a duplicated row in your database is by the use of a
proper natural primary key.

[snippage]

I'm wondering how the same issue is handled in C# in ASP.NET? Do you
essentially do the same thing? ie submit the form to a processing .aspx
file and then redirect back to the dataentry page? Or is there a way of
avoiding duplicate insertions (aside from setting up unique indexes on
the underlying table - unfortunately, duplicates *are* at times
legitimate, so I can't assume that the existence of any duplicate means
that the page was incorrectly refreshed) while still posting back to
the same page?

Hi Dale,

As per my original post, I can't use an index to suppress duplicates,
as duplicates might be the result of legitimate data entry. I'm trying
to remove or minimize the chances of accidental duplicates through
refreshing the page. As I said, in PHP I would have simply passed the
form to a processing page, and redirected back. I was (and still am)
curious to know if C# has an in-built mechanism to deal with this, or
if the same strategy I've used in PHP is the best way to go to achieve
what I'm looking for.

Much warmth,

planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org

[Dale]

If, in the normal course of business, you add duplicate data to the table,
how do you know which to retrieve later?
--
Dale Preston
MCAD C#
MCSE, MCDBA
"planetthoughtful" wrote:

Dale wrote:

As if I haven't been in enough trouble lately, let me assert that the best
way to keep from having a duplicated row in your database is by the use of a
proper natural primary key.

[snippage]

I'm wondering how the same issue is handled in C# in ASP.NET? Do you
essentially do the same thing? ie submit the form to a processing .aspx
file and then redirect back to the dataentry page? Or is there a way of
avoiding duplicate insertions (aside from setting up unique indexes on
the underlying table - unfortunately, duplicates *are* at times
legitimate, so I can't assume that the existence of any duplicate means
that the page was incorrectly refreshed) while still posting back to
the same page?

Hi Dale,

As per my original post, I can't use an index to suppress duplicates,
as duplicates might be the result of legitimate data entry. I'm trying
to remove or minimize the chances of accidental duplicates through
refreshing the page. As I said, in PHP I would have simply passed the
form to a processing page, and redirected back. I was (and still am)
curious to know if C# has an in-built mechanism to deal with this, or
if the same strategy I've used in PHP is the best way to go to achieve
what I'm looking for.

Much warmth,

planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org

[coosa]

I Agree 100% with Dale.
It's a common knowledge to add a primary key in your database table; by
chance perhaps even unique constraints for certain non-key columns.
A good practice is to implement a procedure that inserts records and
the procedure should be inside a SQL TRY CATCH that returns back a user
friendly error that the data already exists.
You cannot rely aalone on the asp.net interface to validate your data.
But even though u don't want to touch that, cosider the Postback in
ASP.NET.

[planetthoughtful]

Dale wrote:

If, in the normal course of business, you add duplicate data to the table,
how do you know which to retrieve later?

Hi Dale,

Lol, I'm surprised this has become such a difficult issue, and that
no-one seems to want to touch my original question, despite it being
extremely legitimate in web design.

Oh well. Cough. Hmmm. Imagine, if you will, a simple web app used to
record activity. Imagine then, that you may perform the same action on
the same task several times. Imagine also that you as a developer have
been asked to build an interface that allows 'type-click-click-submit'
functionality (one text box, two list boxes and a submit button) and,
very importantly, that a user might legitimately record exactly the
same information several times in a row.

Now, imagine that all that's really going to be used out of this is a
count of records per activity, per task, per user id, per day.

Now, just for the sake of the argument, and without running off on a
'unique key! unique key!' tangent, how would you minimize the
opportunity for accidental insertion of duplicate records by a page
refresh?

I've already explained how I would achieve this in PHP. You will see
the "entrypage.php --> processpage.php --> entrypage.php" technique
used a lot on sites for inserting blog comments, for example - where a
page refresh might otherwise insert a duplicate comment, but where
multiple comments by the same person is very normal.

I agree, in principle, that a unique key would have been an ideal
solution, if it were applicable. But, sadly, unless someone can see
something I'm missing, it's not.

Much warmth,

planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org

[coosa]

dataentry.php --> processdataentry.php --> dataentry.php
It can be done in the same matter using asp.net using
Response.Redirect("PageName.aspx");
Hence,
dataentry.aspx -> processdataentry.aspx -> dataentry.aspx.
The Response.Redirect Method can be implemented inside an event of
button vlick for instance or as u wish.
Again, I have faced similar issues of clients requesting me to prevent
the insertion of duplicate records; they also wanted me to NOT touch
the existing database; i did that for them and still emphasized that it
is a POOR design and alternative and a proper one is to rethink the
originla design of the database.
Validation wise, I recommened a double layer way; one on the database
side and one in the interface side.
Yu do not want the clients to get uggly database errors and exceptions
if they attempt to insert duplicate records even though the database
prevents it, then u create in your asp.net page user-friendly
validations as a sub of the primary database validations.

Best regards