December 5, 2003 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/chedgate/dealingwithchangingdata.asp
December 19, 2003 at 4:55 am
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/
December 19, 2003 at 11:29 am
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.
December 20, 2003 at 1:07 am
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/
June 25, 2008 at 8:39 am
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
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply