Generally speaking, when an entity is updated through Telerik Data Access
(when using DateTime
for concurrency checks), the generated update query would specify a filter based on the primary key of the object that is to be updated and the value of the concurrency column at the time when the object was retrieved from the database to assure no updates are to be overridden accidentally.
Therefore I would expect that such optimistic verification exception could be triggered by the following chain of events:
1. An entity was retrieved from the database.
2. Time was automatically changed on the database server.
3. An update for the previously retrieved entity was committed.
If this has happened then the version column check may fail and cause the described issue leading temporary disturbance. All further queries though should continue to work as expected.
Is that the case on your side? Please correct me if I am wrong.
If this is indeed the case, then you could react on that situation by re-retrieving the entity from the database and then retrying the update operation. There is a documentation article that describes in further details how to manage such situations using Telerik Data Access
- please find it here
I hope this is helpful. Do not hesitate to get back to us if you more questions or need any further assistance.
Check out the latest announcement
about Telerik Data Access vNext as a powerful framework
able to solve core development problems.