SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Dealing With Changing Data


Dealing With Changing Data

Author
Message
Chris Hedgate
Chris Hedgate
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2271 Visits: 7
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/chedgate/dealingwithchangingdata.asp

--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
Chris Hedgate
Chris Hedgate
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2271 Visits: 7
I see that I have a slight error in the article text. The following part is not correct:

quote:

This means that data is locked as soon as it is read and no other user is able to read that data until the locking user releases it. The SQL Server way of doing this is of course to use Update Locks instead of Shared Locks when reading data.



Instead, it shoud have been like this:

This means that data is locked as soon as it is read and no other user is able to change that data until the locking user releases it. The SQL Server way of doing this is of course to use Update Locks instead of Shared Locks when reading data.

--
Chris Hedgate @ Extralives (http://www.extralives.com/)
Contributor to Best of SQL Server Central 2002 (http://www.sqlservercentral.com/bestof/)
Articles: http://www.sqlservercentral.com/columnists/chedgate/

--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
bigdmoore
bigdmoore
Valued Member
Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)Valued Member (62 reputation)

Group: General Forum Members
Points: 62 Visits: 1
Good article. Informative, especially for beginners who are starting to deal with this.

One suggestion: In the second to last paragraph you talk "SQL Server's built-in functionality for optimistic concurrency," but don't give any examples of how to implement or use this functionality. I'd like to know more about how to use this.



Chris Hedgate
Chris Hedgate
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2271 Visits: 7
Thanks, maybe I'll get back to that part in another article then.

--
Chris Hedgate @ Extralives (http://www.extralives.com/)
Contributor to Best of SQL Server Central 2002 (http://www.sqlservercentral.com/bestof/)
Articles: http://www.sqlservercentral.com/columnists/chedgate/

--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
billross
billross
SSC Journeyman
SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)

Group: General Forum Members
Points: 86 Visits: 119
Disclaimer: I'm a newbie...

Am I correct that if you merely add a ROWVERSION column to your table that SS will prevent overwriting an interim change, but will not communicate that the update failed?

To my newbie ears, then, this sounds like the simplest approach possible, then, that would be effective.

* add a ROWVERSION column to every table (which one could do automatically, I'm sure)

* add a TRIGGER (AFTER) to every table to check @@ROWCOUNT for zero. If zero, notify the user that their update failed and why.

In your example you use PRINT to report the failure. Is that just an example that will only work in Management Studio, or is that going to work in an app? If not, how does that typically get back to the user?

Thanks,

"What I lack in youth I make up for in immaturity!"
Please visit my music site at http://woundedego.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search