Thanks Greg,
Does that mean rowversion becomes a member of all your entities?
public class EntityA
{
public int Field1 { get; set; }
public byte[] RowVersion { get; set; }
}
?
On 5/02/2013 10:58 AM, Greg Low (GregLow.com) wrote:
Hi Wallace,
The best approaches for this are usually based around the rowversion data
type.
Each table can have a column of type "rowversion". This used to be called
"timestamp".
All it contains is a binary value that changes whenever the data in the row
changes. It does that automatically.
So, the sort of concurrency scheme that you're talking about (even for
disconnected use) can be performed by:
1. Read the data, including the rowversion column.
2. Update the data having the rowversion column in the WHERE predicate.
3. Check whether or not the row was updated. If not, someone else had
already modified it and you need to take appropriate action.
This sort of scheme is far better than anything based around locks, unless
you are talking about really short timespans.
Regards,
Greg
Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com
-----Original Message-----
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
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
