Help! Back button - Redesign Project???

G

Guest

Hello -

Thought I was almost done with my project and then a back arrow button issue
raised its ugly head.

Once a user fills out a form and submits it (done via stored procedure into
a Sql Server database), what's to prevent them from pressing the back button
and resubmitting the form multiple times and creating havoc with my database?
How is this issue usually handled?

Any help will be greatly appreciated!
 
B

billmiami2

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.
 
G

Guest

Thanks for your response, Bill. How would I go about doing that? Here's my
table:

CREATE TABLE [tblPost] (
[PostID] [int] IDENTITY (1, 1) NOT NULL ,
[UserID] [int] NOT NULL ,
[TopicID] [int] NOT NULL ,
[Question] [char] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[PostMsg] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[PostDT] [datetime] NOT NULL CONSTRAINT [DF_tblPost_PostDT] DEFAULT
(getdate()),
CONSTRAINT [PK_tblPost] PRIMARY KEY CLUSTERED
(
[PostID]
) ON [PRIMARY]
) ON [PRIMARY]

Here's my stored procedure:

ALTER Procedure spInsertPostMsg
@UserID int,
@TopicID int,
@Question char(100),
@PostMsg text,

@PostDT datetime = Default,
@PostID int OUTPUT
AS
Insert into tblPost
Values
(
@UserID,
@TopicID,
@Question,
@PostMsg,
GetDate()
)
Declare @Ident int
Select @PostID = @@IDENTITY
Select @Ident = @PostID
******************
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.

I have a date/time column - the entries would never be the same. Is my
logic flawed on this? Also, this table will not be updated - just new
entries added.

I agree this should be done at the DB level -- perhaps at both levels would
be an even better solution . . .

Thanks again!

Sandy
 
G

Guest

Thanks for responding, Juan -

As far as I know, these records will never be duplicates - all of these
records have a date/time field.

Sandy
 
J

Juan T. Llibre

You could also implement some sort of a time
limit needed before a second record can be posted.
 
B

billmiami2

Sandy,

I don't know how you are using your table. If a given user can only
post an entry for the same question once, then you could create a
unique index on the columns UserID and Question.

On the other hand, if you are using the table to capture exchanges
between users where a user posts a question, gets a response but then
the original user later responds to the first respondent and so on
(like this usenet forum), then you will need to allow multiple entries
for the same user/question. You won't be able to restrict postings
based user/question and you can't really restrict postings based on
date/time. In fact, your definition of "duplicate" would involve
checking if the PostMsg text column were the same as in a previous
record for the same user in the table. You can certainly do this, but
now you're dealing with text data types, which are much clumsier to
work with in your stored procedures.

I suppose in this case, you may not have any good options on the
database side except user training! You can also take steps to lower
the likelihood that the user will use the back button. For example, if
a question is successfully posted, the user is told so and furnished
with a convenient link to another part of the application.

I hope that I'm not way off track in my interpretation.

Bill
 
G

Guest

Hi Bill -

No, you're not off track - you got it exactly right! Do you happen to know
how any of these user groups handle this?

Sandy
 
J

James Doughty

I have an app that does onlie transaction and came accrosss the same
problem, I solved it by doing a State machine in my session.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top