Why is this idea bad?

> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
it is not scalable. you incur a database lookup for every post request per
customer. multiply that by a few users and your database will be underload
even when no real work is being done.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@dotnet.itags.org.microsoft.com...
>I was trying to think of ways to stop accidental reposts of data when users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
> do
> a response.redirect to the page so people get a fresh version of it. If
> it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
> to
> expire after a certain time. I was thinking that I would store the guids
> in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
> Thanks, Scottwell how about just taking the button on way on the click with clientside
code. that ensures just one post. if that is what you want to do. need to
re-read this thread again in a bit. but in the meantime, what's wrong with
this suggestion?

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F67EB795-06D6-4CEF-B945-CA6524190627@.microsoft.com...
> Actually every page where this would be used already hits the database at
> least once. Wouldn't this basically be the same thing as Microsoft's
> suggestion to use sql server to store the state of the application.
> "Alvin Bruney [MVP]" wrote:
>> > This idea seems too much of a magic bullet for the re-postback problem,
>> > what
>> > is wrong with it?
>> it is not scalable. you incur a database lookup for every post request
>> per
>> customer. multiply that by a few users and your database will be
>> underload
>> even when no real work is being done.
>>
>> --
>> Regards,
>> Alvin Bruney
>> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
>> Got tidbits? Get it here... http://tinyurl.com/27cok
>> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in
>> message
>> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>> >I was trying to think of ways to stop accidental reposts of data when
>> >users
>> > hit the back button and I came up with an idea.
>>> > If I were to tag every response that I send to the client with a guid
>> > and
>> > then store that guid in a database I could check on the postback to see
>> > if
>> > that request has already been posted. If it has been posted I would
>> > just
>> > do
>> > a response.redirect to the page so people get a fresh version of it.
>> > If
>> > it's
>> > the first post back I could delete the guid from the database as being
>> > a
>> > valid response. I would also have to timestamp each entry to allow
>> > them
>> > to
>> > expire after a certain time. I was thinking that I would store the
>> > guids
>> > in
>> > sql server.
>>> > This idea seems too much of a magic bullet for the re-postback problem,
>> > what
>> > is wrong with it?
>>> > Thanks, Scott
>>
>>
>
Taking away the submit button wouldn't work well for if they hit the back
button to get to another post back. In other words the user clicks the add
user button then edits the new user and clicks the save user button, when
they hit the back button after hitting the save button it will be
re-submitting the add user button. I can't just disable the add user button
because it could be a valid action if actually clicked. Most of the time
it's just that users hit the back button and ends up with another user.

"Alvin Bruney [MVP]" wrote:

> well how about just taking the button on way on the click with clientside
> code. that ensures just one post. if that is what you want to do. need to
> re-read this thread again in a bit. but in the meantime, what's wrong with
> this suggestion?
> --
> Regards,
> Alvin Bruney
> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
> Got tidbits? Get it here... http://tinyurl.com/27cok
> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
> news:F67EB795-06D6-4CEF-B945-CA6524190627@.microsoft.com...
> > Actually every page where this would be used already hits the database at
> > least once. Wouldn't this basically be the same thing as Microsoft's
> > suggestion to use sql server to store the state of the application.
> > "Alvin Bruney [MVP]" wrote:
> >> > This idea seems too much of a magic bullet for the re-postback problem,
> >> > what
> >> > is wrong with it?
> >> it is not scalable. you incur a database lookup for every post request
> >> per
> >> customer. multiply that by a few users and your database will be
> >> underload
> >> even when no real work is being done.
> >>
> >> --
> >> Regards,
> >> Alvin Bruney
> >> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
> >> Got tidbits? Get it here... http://tinyurl.com/27cok
> >> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in
> >> message
> >> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
> >> >I was trying to think of ways to stop accidental reposts of data when
> >> >users
> >> > hit the back button and I came up with an idea.
> >> >> > If I were to tag every response that I send to the client with a guid
> >> > and
> >> > then store that guid in a database I could check on the postback to see
> >> > if
> >> > that request has already been posted. If it has been posted I would
> >> > just
> >> > do
> >> > a response.redirect to the page so people get a fresh version of it.
> >> > If
> >> > it's
> >> > the first post back I could delete the guid from the database as being
> >> > a
> >> > valid response. I would also have to timestamp each entry to allow
> >> > them
> >> > to
> >> > expire after a certain time. I was thinking that I would store the
> >> > guids
> >> > in
> >> > sql server.
> >> >> > This idea seems too much of a magic bullet for the re-postback problem,
> >> > what
> >> > is wrong with it?
> >> >> > Thanks, Scott
> >>
> >>
> >>
>