At what level are you looking at this problem? For example SQL Server has native support for cursors and locks: you could (again, for example) ensure that every record in your SELECT statement is clean (RepeatableRead), i.e. no one else has changed a record even whilst SQL Server is assembling the result set. However, this isn't particularly helpful if you then disconnect the dataset (e.g. display the results in a web page), and allow the user some minutes to make changes before then putting the changes back into the DB.
Cheers Ken -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wallace Turner Sent: Tuesday, 5 February 2013 12:54 PM To: ozDotNet Subject: sql server concurrency and 'conflicting' updates i have googled a bit for this but fear i am missing an important keyword. What methods are used to handle concurrent updates in sql server? That is, two users editing the same 'thing'. The way ravenDB does it [1] looks good to me. What support is there for approaches of this type (using etags) in sql server? Could you also discuss what you allow the end users to see/do? eg are they given options to 'ignore clash and override' [1]: http://ravendb.net/docs/http-api/http-api-comcurrency
