Help! Back button - Redesign Project???

[Sandy]

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!
--
Sandy

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

[Juan T. Llibre]

re:

How is this issue usually handled?
By not accepting duplicate records in the database.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:4B******** *************** ***********@mic rosoft.com... 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!
--
Sandy

[Sandy]

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_Gene ral_CP1_CI_AS NOT NULL ,
[PostMsg] [text] COLLATE SQL_Latin1_Gene ral_CP1_CI_AS NULL ,
[PostDT] [datetime] NOT NULL CONSTRAINT [DF_tblPost_Post DT] 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

"bi********@net scape.net" wrote:
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.

[Sandy]

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

"Juan T. Llibre" wrote:

re:

How is this issue usually handled?

By not accepting duplicate records in the database.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:4B******** *************** ***********@mic rosoft.com...

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!
--
Sandy

[Juan T. Llibre]

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

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:C6******** *************** ***********@mic rosoft.com...

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

"Juan T. Llibre" wrote:

re:

> How is this issue usually handled?

By not accepting duplicate records in the database.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:4B******** *************** ***********@mic rosoft.com...

> 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!
> --
> Sandy

[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

[Sandy]

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

"bi********@net scape.net" wrote:

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

[Sandy]

Hi Juan -

Any ideas on how to go about doing that?

Sandy

"Juan T. Llibre" wrote:

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

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:C6******** *************** ***********@mic rosoft.com...

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

"Juan T. Llibre" wrote:

re:
> How is this issue usually handled?

By not accepting duplicate records in the database.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:4B******** *************** ***********@mic rosoft.com...
> 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!
> --
> Sandy

[Juan T. Llibre]

Check out the source code for the Community Server Forums.
They do just that.

http://www.communityserver.org/forums/

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:31******** *************** ***********@mic rosoft.com...

Hi Juan -

Any ideas on how to go about doing that?

Sandy

"Juan T. Llibre" wrote:

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

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

"Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
news:C6******** *************** ***********@mic rosoft.com...

> 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
>
> "Juan T. Llibre" wrote:
>
>> re:
>> > How is this issue usually handled?
>>
>> By not accepting duplicate records in the database.
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> http://asp.net.do/foros/
>> Foros de ASP.NET en Español
>> Ven, y hablemos de ASP.NET...
>> =============== =======
>>
>> "Sandy" <Sa***@discussi ons.microsoft.c om> wrote in message
>> news:4B******** *************** ***********@mic rosoft.com...
>> > 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!
>> > --
>> > Sandy