Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / General / December 2007

Tip: Looking for answers? Try searching our database.

Optimistic concurrency.  I've found a ridiculously easy method.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
B. Chernick - 18 Dec 2007 15:44 GMT
(If I'm overlooking anything, please let me know.)

First, my only concern is updating single records in a Detailsview using an
ObjectDataSource.  The target table has a timestamp field.  Assume  a  single
primary key.  

Create your xsd.  Drag the table onto the xsd.  Then manually edit the
Update statement to simplify it.  Essentially 'Update <table> set blah = blah
Where (PK=@PK) and (ts=@ts)'.  (Get rid of all that auto-generated 'original'
stuff.  Also those IsNulls.  They don't seem to serve any purpose except to
confuse. Don't use the Optimistic Concurrency option in the wizard.)

Get the record into the detailsview any way you see fit.  I generally use
the first select statement to populate a grid and then call the detailsview
through a hyperlink.  Then I create a 2nd select by PK.

Bind your detailsview.  Here's the critical step.  Add the timestamp field
to the DataKeyNames property of the detailsview (since the timestamp datatype
can't be passed any other way apparently.)

Next, add the following code to the Object Data Source Updating event
handler:         e.InputParameters.Item("ts") = DetailsView1.DataKey.Item(1)

That's it.  The only other thing you really have to do is check the
e.ReturnValue in the Object Data Source Updated.  1 is success, 0 is failure.
(For some reason the AffectedRows parameter is always returning -1)

Apparently if you use this sort of method, you are responsible for reporting
success or failure on the webpage.  (Actually I was expecting a crash when I
tried to update an already updated record, but so much the better.)

One last question:  Why have I not seen this in any tutorial?
sloan - 18 Dec 2007 15:58 GMT
I think you've got a good tutorial, but I don't think you've discovered
anything new.

http://www.google.com/search?hl=en&q=timestamp+optimistic+%22sql+server%22

http://davidhayden.com/blog/dave/archive/2005/10/05/2503.aspx
Optimistic Concurrency Strategies
If you are in a performance state-of-mind, chances are you will go with
optimistic concurrency.  Optimistic concurrency frees up database resources
as quickly as possible so that other users and processes can act upon that
data as soon as possible.

To the best of my knowledge, there are four popular strategies to dealing
with optimistic concurrency:

 1.. Do Nothing.
 2.. Check for changes to all fields during update.
 3.. Check for changes to modified fields during update.
 4.. Check for changes to timestamp ( rowversion ) during update.

I agree the N number of "OriginalThis" and "OriginalThat" is a pain is
overkill and ugly and non maintainable.

..

Start a blog, post your tutorial...then others can learn from your example.

Windows Live has free blog space.

http://sholliday.spaces.live.com/blog/

> (If I'm overlooking anything, please let me know.)
>
[quoted text clipped - 39 lines]
>
> One last question:  Why have I not seen this in any tutorial?
B. Chernick - 18 Dec 2007 16:25 GMT
No argument here.  But that's the problem.  It's not clearly spelled out with
all the bits in one place, anywhere it might be easily found, at least
nothing that I've noticed until now.  It was almost a matter of chance that I
stumbled across the right keywords and Google hit.  (Doubly frustrating when
you're under a deadline and new to ASP.Net 2.0.  Admittedly, you miss stuff
when you're rushing.)  

So hopefully others will avoid my frustration.

> I think you've got a good tutorial, but I don't think you've discovered
> anything new.
[quoted text clipped - 70 lines]
> >
> > One last question:  Why have I not seen this in any tutorial?
Scott Roberts - 18 Dec 2007 18:11 GMT
I don't think that the timestamp method is "bad", per se, but I much prefer
checking modified fields.

The problem with timestamps is that they give "false positives" - meaning
that a user may encounter a "concurrency error" when none really exists. For
example, one user changes the address and another user changes the phone
number. There is no concurrency issue there, but the timestamp method will
report one anyway.

It depends on your application requirements, how many concurrent updates you
expect to see, and how difficult it is for users to recover from concurrency
issues. The timestamp approach seems to be pretty easy to implement, and if
time is the limiting factor that they are probably the way to go.

> I think you've got a good tutorial, but I don't think you've discovered
> anything new.
[quoted text clipped - 72 lines]
>>
>> One last question:  Why have I not seen this in any tutorial?
B. Chernick - 18 Dec 2007 20:10 GMT
Interesting point.  In a high volume system, that might be a consideration.  
I think that in my current environment (a relatively low volume system)
'false positive' would be a matter of semantics.  Only one person should be
modifying any one record at any time. (Can't have managers stepping on each
other's toes.)  

As you point out, application requirements decide this.

(From a personal point of view, given my experiences, I would be
uncomfortable with letting 2 different users change 2 different fields in a
record simultaneously.  That just feels like trouble to me.)

> I don't think that the timestamp method is "bad", per se, but I much prefer
> checking modified fields.
[quoted text clipped - 86 lines]
> >>
> >> One last question:  Why have I not seen this in any tutorial?

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.