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 Marsh

Chris,

See in-line comments.

-- Bill

"Chris" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.

[..]

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

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.

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

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

Hi Chris,

Based on my understanding, your question is:
1) You want to break the user registration process into two steps: User
enters data in the first page, after the "Proceed" button is clicked, the
data gets validated (unique email address and so on) and if correct,
redirects to second page and let user preview the data that will be
submitted to database.

2) You're concerned about database concurrency since the email address must
be unique, it's possible that before one user's data gets submitted to
database, there might be also other requests checking the uniqueness of
email address using the not-modified user table.

3) Using temporary table is not viable since it's not easy to maintain.

Please correct me if I've misunderstood anything.

I also don't recommend the temporary table approach since it makes checking
for email address uniqueness difficult, and when user closes the second
page without submitting, you get "dead" data in the temporary table and
prevent users from using the email address again.

Since the registration process has to be separated into two steps, I'm
afraid you will have to validate data in each step. The data that has been
collected in the first step could be stored in the session state, or use
other two approaches:

1) Use the same page as the two steps, you can use Wizard or MultiView
control to present different view of the data to user in different step.

2) Use cross-page postback to post the data from the first page to second
page.

Let me know if you want more information on related topics.

Hope this helps.

Sincerely,
Walter Wang ((E-Mail Removed), remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.