Yep, I tend to call it a name like "Concurrency" or something, with a data type of "rowversion". I'd try to avoid naming the column after a data type. While you can, I wouldn't :-)
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 3:14 PM To: ozDotNet Subject: Re: sql server concurrency and 'conflicting' updates 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 >
