Yes, I would agree... seems like SQL should be rejecting this change and it should be caught by MM (assuming you're using optimistic locking, which should be the default). I've seen this in action myself, although that was with SQL 2000. Hopefully, it's not a SQL version issue. I'd suggest putting a breakpoint in

public virtual mmSaveDataResult SaveDataSet(DataSet ds, string tableName, string databaseKey,
IDbDataAdapter dbAdapter)

It's in mmBusinessObject.cs and you're looking for this line

RecordsUpdated = dao.SaveDataSet(ds, 
	tableName, 
	PK, 
	RetrieveAutoIncrement,
	dbAdapter);

I'm showing it as starting on line 4271. If it doesn't throw an exception, I would go back and step into this method, checking the UPDATE command. If you haven't built your own, it should include a lot of extra code to check each column's current vs. previous values. That's what should eventually trigger the concurrency exception further down the code path.

Hope that helps,
---J

>Thanks for your reply J.
>
>By "ignoring it", i mean that no DBConcurrencyException is being thrown.
>
>Example
> - Data retreieved by a BizObj (SQL 2005)
> - data change via another soucre in the database
> - attemtp tosave data via BizObj and the data is successfully written.
>
>Shouldn't this throw a DBBConcurrentException since the data now in the database does not match what the "original" state business object thought it was??
>
>So this is where my question about the extent to which MM handles concurrency and it's resolution?