Hi Jerry,
Thanks for that. My webform is indeed submitting to a database. I don't want
to create another success page because it is expected by the sponsor that
the success page is essentially the submit page with (for want of a better
description) locked controls. And the sponsor has had a track record of
wanting to edit the text content of the page(s) thus causing irritating
errors as both pages have to be kept up to date (was a pain in asp, less so
in asp.net).
So my current design proposal is that the submit page is the success page.
I was toying with the idea of using session variable(s) as identifiers/flags
or database search for duplicate entry. I'm going the database way as the
amount of traffic is not expected to be heavy - I suppose session variables
are less scalable but that does not concern me at this stage.
You bring up multi-page forms. An excellent segue to making survey forms --
What is the optimum approach for reliable survey forms?
One simple way is to store the values as session variables - that means
regardless of how many webpages you make up, we have a mechanism to iterate
and handle them.
However, my one attempt to do that was not very reliable.
a. the session variables somehow got lost possibly with the forward / back
or the postbacks caused by validation controls.
b. of course if the session was dropped somehow, the web visitor had no
saved record.
So... does this mean that
a. one captures the visitor id and stores it in db on the initial greeting
page?
b. that one keeps going to the record(s) in the db for saves as well as
forward/back navigation?
thanks
Ananda
