SQLServerCentral / Discuss Content Posted by Christoffer Hedgate / Article Discussions / Article Discussions by Author / Dealing With Changing Data / Latest Posts

RE: Dealing With Changing Data

billross — Wed, 25 Jun 2008 08:39:33 GMT

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,

RE: Dealing With Changing Data

Chris Hedgate — Sat, 20 Dec 2003 01:07:00 GMT

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/

RE: Dealing With Changing Data

bigdmoore — Fri, 19 Dec 2003 11:29:00 GMT

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.

RE: Dealing With Changing Data

Chris Hedgate — Fri, 19 Dec 2003 04:55:00 GMT

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/

Dealing With Changing Data

Chris Hedgate — Fri, 05 Dec 2003 00:00:00 GMT

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/chedgate/dealingwithchangingdata.asp