Validation controls and DB transactions

[J055]

Hi

I've been puzzling over this one for a while now. I'm not really sure what
the best and cleanest approach would be here. This is what I want to do.

A User enters some values in a FormView control and submits the form.
A CustomValidator checks the database for duplicate entries. If a duplicate
is found the Page.IsValid property is made false and the user gets the error
message. If the Validation passes the ObjectDataSource control calls the
Insert method (or Update) of the BLL class and does the DB operation.
Standard stuff then.

The problem with the above is that it is not contained within a DB
transaction. If another user entry with the same values occurs in between
the first Validation and Insert functions then an SqlException will be
thrown with a unique constraint error.

I've thought of not using the Validation control and instead relying on a
custom exception based on the SqlException and checking for it in the
ObjectDataSource Inserted and Updated events. I don't like this because it
relies on the database having the correct constraints setup and when the
Inserted event fires the FormView control clears the input controls values.

So my questions are - can I make the CustomValidator and Insert/Update code
participate in the same DB transaction? I can't see how. Or is there another
way of achieving these requirements using sound practises together with the
standard server controls?

Many thanks
Andrew

[bruce barker]

see the SqlTransaction class.

note. just using begin tran will not solve your problem. because your
check for existence and insert are two statements, you will still get
constraint errors.

if you really need to avoid the error (rather than catch and try again)
at the cost of scaling, you need to take an exclusive lock on the read
(this will prevent the other validator from reading the table) and
release at the update.

-- bruce (sqlwork.com)
J055 wrote:

Hi

I've been puzzling over this one for a while now. I'm not really sure what
the best and cleanest approach would be here. This is what I want to do.

A User enters some values in a FormView control and submits the form.
A CustomValidator checks the database for duplicate entries. If a duplicate
is found the Page.IsValid property is made false and the user gets the error
message. If the Validation passes the ObjectDataSource control calls the
Insert method (or Update) of the BLL class and does the DB operation.
Standard stuff then.

The problem with the above is that it is not contained within a DB
transaction. If another user entry with the same values occurs in between
the first Validation and Insert functions then an SqlException will be
thrown with a unique constraint error.

I've thought of not using the Validation control and instead relying on a
custom exception based on the SqlException and checking for it in the
ObjectDataSource Inserted and Updated events. I don't like this because it
relies on the database having the correct constraints setup and when the
Inserted event fires the FormView control clears the input controls values.

So my questions are - can I make the CustomValidator and Insert/Update code
participate in the same DB transaction? I can't see how. Or is there another
way of achieving these requirements using sound practises together with the
standard server controls?

Many thanks
Andrew

[Steven Cheng[MSFT]]

Hi Andrew,

I agree to Bruce's suggestion here. Actually making the two operation(query
existing name from db table and insert new record with the name to db
table) in a transaction will only make the two operation set atomic, but
you will still encounter concurrent inserting issue that cause the
duplicated inserting error at inserting time. Also I have discussed with
other DB engineers and this scenario is not quite suitable to implement at
DB level(through transaction or explicit locking , no record to lock).

I think you can consider the following approachs to prevent duplicated
inserting in application code layer:

**Making the data accessing class (do the query and insert) methods a
contral entry point in your application. Thus, you can perform explicit
lock/exclusive against the methods calls. This will hit concurrent
processing performance but is acceptable if there won't frequent occur such
read/inserting operations in your application.

** Add a global inserting id/name list(a limited queue) in your
application, this list will contains all the current/recent item name being
inserted(in sequence). Thus, when you perform inserting, you will need to
check both the DB and this list to see whether there're duplicated existing
record or any one being inserted now.

How do you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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.

[Steven Cheng[MSFT]]

Hi Andrew,

Have you got any progress or does our suggestion in previous messages help
you some? If there is anything else we can help, please feel free to post
here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.