RE: sql server concurrency and 'conflicting' updates

2013-02-04 Thread Ken Schaefer
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

Re: sql server concurrency and 'conflicting' updates

2013-02-04 Thread Wallace Turner
probably 'higher' than that... i'm saving some fairly complex top level objects using nhibernate. On 5/02/2013 10:32 AM, Ken Schaefer wrote: 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 t

RE: sql server concurrency and 'conflicting' updates

2013-02-04 Thread Greg Low (GregLow.com)
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,

Re: sql server concurrency and 'conflicting' updates

2013-02-04 Thread Wallace Turner
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 ar

RE: sql server concurrency and 'conflicting' updates

2013-02-04 Thread Greg Low (GregLow.com)
+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 'confl