Optimimisc Concurrency violation errors are caused by several users updating the same data at once. If you have an optimisitc concurrency violation error even if when there's no other users accessing the same data, than you likely have a bug due to a specific column being updated in a different manner.
Run the application with the debugger attached, and reproduce the use case that creates the concurrency violation. If you look at the output dialog, you'll find some information in there about the columns that are triggering the concurrency violation.
After you find which column is triggering the concurrency error, you need to confirm the suspicion, that the column is being updated with a different approach. Usually, you'll find that one of the reasons below is true:
- That column is updated by a database trigger (eg: UPDATE_DATE and UPDATE_USER or other timestamps are common scenarios);
- That column is updated by a data command or stored procedure in the RowUpdating event or similar;
After you've confirmed the initial suspicition, you can go to the manager of that block, look for the item mapping of that item and change a flag called “disableConcurrencyCheck”. This is the common scenario, when a column might need to be excluded from the optimistic concurrency check, because it is updated in another way.