469,913 Members | 2,648 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,913 developers. It's quick & easy.

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

(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 <tableset 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?
Dec 18 '07 #1
1 1881

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...2sql+server%22

http://davidhayden.com/blog/dave/arc...0/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/

"B. Chernick" <BC*******@discussions.microsoft.comwrote in message
news:95**********************************@microsof t.com...
(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 <tableset 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?

Dec 18 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Chris Huddle | last post: by
2 posts views Thread by John | last post: by
9 posts views Thread by corey.coughlin | last post: by
2 posts views Thread by stuart.d.jones | last post: by
reply views Thread by russganz | last post: by
4 posts views Thread by Andrew Robinson | last post: by
1 post views Thread by =?Utf-8?B?Qi4gQ2hlcm5pY2s=?= | last post: by
8 posts views Thread by Roger.Noreply | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.