J
Jack
Hi,
I am trying to design optimistic concurrency in my application. The
application connects to a MS SQL server and is 3 to 5 user concurrent
application. The application works with one record at a time (ranges from 8
to 12 tables) and if the update fails everything is rolledback via the
transaction object. So, if the record is being updated by another user, I do
not want to update pieces of the data that is not locked (could happen). I
was thinking about implementing on the main table (similiar to Order table
in Northwind) either a timestamp column or datetime column which would be
used to test before the update. Is this a good approach? I rather not have
a column in each table because I do not want to update pieces, I want to
update the whole record or nothing at all. I know I could do this rather
easily by using pestimistic concurrency however I want a scalable solution
and I do not want to keep the connection open. Any suggestions?
Thanks
I am trying to design optimistic concurrency in my application. The
application connects to a MS SQL server and is 3 to 5 user concurrent
application. The application works with one record at a time (ranges from 8
to 12 tables) and if the update fails everything is rolledback via the
transaction object. So, if the record is being updated by another user, I do
not want to update pieces of the data that is not locked (could happen). I
was thinking about implementing on the main table (similiar to Order table
in Northwind) either a timestamp column or datetime column which would be
used to test before the update. Is this a good approach? I rather not have
a column in each table because I do not want to update pieces, I want to
update the whole record or nothing at all. I know I could do this rather
easily by using pestimistic concurrency however I want a scalable solution
and I do not want to keep the connection open. Any suggestions?
Thanks