Re: Help! Back button - Redesign Project???

Sandy,

The best way to protect the database is to build protection into the
database. Do you have primary keys and unique indexes appropriately
designated in your database? If not, you should definitely put them
in.

A unique index can protect you from users inserting duplicate records
in subsequent posts. Subsequent submittals of the form with the same
data would likely violate one of your constraints and no duplicate
record would be inserted. An error can be returned to the user stating
what happened.

For updates, use a concurrency ID on the table that increments for each
successive update for each record. You can use a trigger to do the
incrementing. In your update procedure, check for the value of the
concurrency ID as it is in the form (you can store it in a hidden text
field). If it is not equal to the value in the database for the
selected record, your procedure can return an error, which can be
displayed to the user. Use of the back button will always return an
obsolete concurrency ID and will never result in an update. This
technique will also protect you from cases where a user overwrites
changes made by another user.

I think that ensuring integrity at the database level is preferable to
doing so in the application. If you rely on the application and users
access the data from outside the application, you have no protection.

The last thing that you want to do is to start wrestling with the
user's browser.

Bill E.

.