Write Conflicts - even with me.dirty

Question

In an application that I am writing, I am getting Write Conflicts when I use VBA code to change the value of a checkbox on a form. I have tried inserting the following code into the events that have VBA changing the values of any object on the form:

If Me.Dirty Then
    Me.Dirty = False
End If

But the problem persists - as if the record is not being saved before I look to change anything through manual manipulation.

Here is some examples of the full code from the form where I am encountering this problem:

Code for when Blank Pricing checkbox is changed:

Private Sub chkSupAllowBlankPrice_AfterUpdate()

    If Me.Dirty Then
        Me.Dirty = False
    End If

    If (chkSupAllowBlankPrice.Value = True) Then
        chkSupRequirePrice.Value = False
    End If
End Sub

Code for when Require Pricing checkbox is changed:

Private Sub chkSupRequirePrice_AfterUpdate()
    If Me.Dirty Then
        Me.Dirty = False
    End If

    If (chkSupRequirePrice.Value = True) Then
        chkSupAllowBlankPrice.Value = False
        chkSupAllowBlankPrice.Visible = False
        chkSupAllowBlankPrice.Enabled = False
        chkSupAllowBlankPrice.Locked = True
        lblSupAllowBlankPrice.Visible = False
    Else
        chkSupAllowBlankPrice.Visible = True
        chkSupAllowBlankPrice.Enabled = True
        chkSupAllowBlankPrice.Locked = False
        lblSupAllowBlankPrice.Visible = True
    End If
End Sub

Not sure if it helps, but the tables are stored in a SQL Server express database - hence the tag.

-- Edited 05/29/2009 @ 1201 hours --

I have tried commenting out all object value changes, leaving in only visible, locked, and enabled changes - but I keep getting write conflicts. I tried putting the Me.Dirty = False at the end of the event procedure, and I even tried to remove it. So far, I am getting write conflicts whenever I change Require Pricing or Allow Blank Pricing, without the other value being changed by VBA code.

-- Edited 05/29/2009 @ 1318 hours --

The fields that these checkboxes manipulate -will not- accept any changes once the record is created, generating a Write Conflict any time I attempt to work with them. Now I am totally confused, thinking of gutting everything and starting over.

-- Edited 06/01/2009 @ 1209 hours --

After investigation, it seems there is a number of check constraints defined on the server for the tables involved which I cannot remove. Something is causing the linked tables to always report dirty even when items have not been changed - and I think Access and SQL are fighting it out with default values. I am going to wipe all tables, delete all information, and start over with my design, as the check constraints don't appear to be removable without dropping the table anyway. Thank you everyone for the help, could this question be closed - referring the problem to this new question (Updates to Records not allowed - Write Conflict)?

-- Edited 06/03/2009 @ 1307 hours --

Cross-posted from other question, solution described below for all that were curious. Thank you to all the people who banged their heads with me to get this far, I really aprpeciate the help. I found out that a strange problem that crops up when using Yes/No checkboxes and SQL Server with Access. Apparently, Access will interpret NULL as No - changing the value, but SQL Server will not interpret NULL as a No in a Bit field (what Yes/No gets turned into in conversion) so it throws a Write Conflict error when a value is not required, and is NULL. The solution was to redesign the table so that a value was required, and that there was a default value assigned for EVERY former Yes/No checkbox. This solved the mysterious Write Conflict messages, and allowed changes to records once they were created.

Answer 1

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.

Answer 2

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.

Answer 3

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.