Would you rather use a version number (that will increment) or a timestamp to check for concurrency problems?
The following tables follow an example of optimistic concurrency. At 1:01 p.m., User2 reads the same row. At 1:03 p.m., User2 changes FirstName from "Bob" to "Robert" and updates the database. The update succeeds because the values in the database at the time of update match the original values that User2 has.
To have this TableAdapter employ optimistic concurrency control, simply check the "Use optimistic concurrency" checkbox. Lastly, indicate that the TableAdapter should use the data access patterns that both fill a DataTable and return a DataTable; also indicate that the DB direct methods should be created.
Optimistic concurrency derives its name from the optimistic assumption that collisions between transactions will rarely occur; a collision is said to have occurred when another transaction updates or deletes a row of data between the time it is read by the current transaction and the time it is updated or deleted.
Optimistic locking is a technique for SQL database applications that does not hold row locks between selecting and updating or deleting a row. The application is written to optimistically assume that unlocked rows are unlikely to change before the update or delete operation.
Version number is better because no matter what format of time you use, it can still be thrown off if the server's clock is wrong or becomes wrong over time.
I have to admit, I've used a time stamp in many databases because it can serve a dual purpose of concurrency checking as well as readability for when the data was last changed. However, using a version number is really the better way to go.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With