Customer Registration - Temporary data storage

All
I am cross-posting, as I'm not sure if this is an issue for the data layer
or the application layer. If this is unacceptable, can someone let me know
so that I don't do this in future.
I'm using ASP .NET, framework version 1 and SQL Server 2000.
I have an ASPX page with a form for customers to register. When they click
on the "Proceed" button, they are shown a preview page of the data that they
are submitting. They can then either click on an "Edit" button to return to
the form, or click on the "Submit" button to create their account.
My question is: what is the best way to handle the data between the time
that the customer clicks on the "Proceed" button in the original form, and
the customer clicks on the final "Submit" button?
The two issues that I see are concurrency (the email address must be unique
within the database table), and performance. I was told by a colleague that
using a seperate database table to store the data from the original form
submission and then selecting from this table into the Customer table when
the customer clicks on the final "Submit" button poses less of a risk of
locking the Customer table than inserting directly into the Customer table.
Is this correct? Should I be using the database to store temporary data, or
use the built-in ASP .NET state maintenance objects?
Many thanks in advance for any insight.
Regards
Chris MarshChris,
See in-line comments.
-- Bill
"Chris" <cjm@.newsgroup.nospam> wrote in message
news:u8lk0LNMHHA.1240@.TK2MSFTNGP03.phx.gbl...
> All
> I am cross-posting, as I'm not sure if this is an issue for the data layer
> or the application layer. If this is unacceptable, can someone let me know
> so that I don't do this in future.
> I'm using ASP .NET, framework version 1 and SQL Server 2000.
> I have an ASPX page with a form for customers to register. When they click
> on the "Proceed" button, they are shown a preview page of the data that
> they are submitting. They can then either click on an "Edit" button to
> return to the form, or click on the "Submit" button to create their
> account.
> My question is: what is the best way to handle the data between the time
> that the customer clicks on the "Proceed" button in the original form, and
> the customer clicks on the final "Submit" button?
> The two issues that I see are concurrency (the email address must be
> unique within the database table), and performance. I was told by a
> colleague that using a seperate database table to store the data from the
> original form submission and then selecting from this table into the
> Customer table when the customer clicks on the final "Submit" button poses
> less of a risk of locking the Customer table than inserting directly into
> the Customer table.
I agree in principle. This all falls under the category of session state. In
addition to the customer entered data, you could also keep other session
information in that same table: IP address, affiliate codes, session
duration, click-stream.
If your website is successful, this information will become valuable in
analyzing the user experience and calculating abandon rates.

> Is this correct? Should I be using the database to store temporary data,
> or use the built-in ASP .NET state maintenance objects?
If you use .NET there are special considerations if you are going to farm
your web tier: sicky ip, etc.

> Many thanks in advance for any insight.
> --
> Regards
> Chris Marsh
>|||Bill
Firstly, thanks a lot for the response.
[..]

> I agree in principle. This all falls under the category of session state.
> In addition to the customer entered data, you could also keep other
> session information in that same table: IP address, affiliate codes,
> session duration, click-stream.
> If your website is successful, this information will become valuable in
> analyzing the user experience and calculating abandon rates.
Session management in a broader sense is beyond the scope of this particular
task, so although I agree totally that this data is important, it's
irrelevant to my query.
Since submitting my initial query, I've realised that there is a gaping
(non-technical) flaw in storing this data at all. If the user closes the
browser before completing the process, they have not agreed to the terms and
conditions and privacy policy. Yet, we would be storing personally
identifiable information about this user. I believe that this contravenes
the Data Protection Act in the UK.

> If you use .NET there are special considerations if you are going to farm
> your web tier: sicky ip, etc.
Indeed. Currently the platform I'm working on is a single server, so session
state management is in-process.
Thanks again for getting back to me.
Regards
Chris Marsh