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

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

"billmiami2@xxxxxxxxxxxx" 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.
>
>
.