Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Dealing With Changing Data Expand / Collapse
Author
Message
Posted Friday, December 5, 2003 12:00 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, 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/
Post #18918
Posted Friday, December 19, 2003 4:55 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, 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/
Post #90125
Posted Friday, December 19, 2003 11:29 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 21, 2004 10:57 AM
Points: 42, 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.






Post #90126
Posted Saturday, December 20, 2003 1:07 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, 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/
Post #90127
Posted Wednesday, June 25, 2008 8:39 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, March 14, 2010 9:41 PM
Points: 56, 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
Post #523429
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse