IN the past, I've had some wierd problems in Access occur if the SQL Server linked table did not have a primary key. If your table doesn't have a primary key, it doesn't know which record to update. I know I got a similar message for this once but it was years ago, so I don't know if this is your problem.
A few comments:
is there any particular reason you save the form's data (set Dirty=false) before changing the other field's value (which will make the form dirty again)?
I would first change the other field's data then save the form's data, otherwise the form is always dirty.
changing control's values from code does not call their events, so changing chkSupRequirePrice's value from chkSupAllowBlankPrice_AfterUpdate() will not call chkSupRequirePrice_AfterUpdate().
Instead of putting specific code into each event, it's better to regroup everything into the same, say, Update() sub called from each event handler.
It will make it easier to manage you code and its side effects because it's the same piece of code that's called all the time.
having said that, your code should work, so I'm guessing the issue comes from somewhere else in your code.
Write conflicts happen if the same record is already opened for editing elsewhere.
You can play around with the type of locking and see if it changes anything.
to see if the issue is really related to your SQL Server setup, try to unlink the table and instead copy it into your local Access database to see if you're still getting this issue when dealing with a local Access table.
There is a difference between how Access handles Yes/No checkbox values and SQL Server. When translating Yes/No booleans from Access to SQL Server, you must remember to define a default state as well as mark it as requiring an answer. Otherwise, you will get write conflicts every time, and it will prevent the record from being saved with your changes once the initial values have been set.