OK, if no exception is being thrown, then I see 2 possibilities...

1. Your update command isn't being built with optimistic concurrency in mind. Did you create a custom data adapter, possibly using an adapter wizard? There is a setting on the wizard to tell the adapter whether or not to use optimistic concurrency.

2. Somehow, you're re-populating your dataset somewhere in the middle with the changed data so the concurrency problem doesn't exist after that.


You can test by setting a breakpoint on line 914 of mmDataAccessSQL:

RowsUpdated = DataAdapter.Update(ds, ds.Tables[tableName].ToString());

And check the DataAdapter's UpdateCommand... it should have code that looks something like this if it's set for optimistic concurrency:

SET CustomerID = @CustomerID, CompanyName = @CompanyName, ContactName 
= @ContactName, ContactTitle = @ContactTitle, City = @City
WHERE (CustomerID = @Original_CustomerID) AND (City = @Original_City 
OR @Original_City IS NULL AND City IS NULL) AND (CompanyName = 
@Original_CompanyName) AND (ContactName = @Original_ContactName OR 
@Original_ContactName IS NULL AND ContactName IS NULL) AND (ContactTitle = 
@Original_ContactTitle OR @Original_ContactTitle IS NULL AND 
ContactTitle IS NULL)

Either way, I would wait until you hit this breakpoint before making the new change on the backend. That should eliminate the possiblity of extraneous, "rogue" code being the culprit. Then, try the save and see if you get the concurrency exception.

---J

>J,
>
>I have stepped through the code and no exception is being thrown. I have not set my own UPDATE command, and MM doesn't appear to be running through any code that is performing these checks.
>
>Is it possible that something on my businuess object/SQL may not be set correctly?
>
>Well yes, it is possible, what i mean is, what settings (if not correct) may cause this behaviour?)