Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1302
  • Last Modified:

Replicitable "Write Conflict" error with Access 2003 linked to MySQL 5.0

The problem is as follows:

1. To use ODBC and Access to update a MySQL table, you need to have a TIMESTAMP type (any field name will do) in the record, and for it to be updated automaticalyl (which is the default behaviour for this data type in MySQL).

2. If you update a record in a MySQL database via ODBC, and the values of EVERY field is the same as the current record, the timestamp field is NOT updated. This seems to be intentional behaviour by MySQL as I found some blogs about MySQL actually doing the update in this case and that this was considered a bug.

3. If you edit a field but set it to the SAME value it had before, the client tries to save the record but the clever MySQL system decides that since the data has not actually changed, it does not change the TIMESTAMP field.

4. In MS-Access, this seems to cause Access to think that someone else has updated the record before you, and it shows the "Write Conflict" popup message. While this doesn't entirely make sense to me as I am not sure how it uses the TIMESTAMP field, it is definitely the reason for the problem. It also doesn't cause any lost data if you just "Drop Changes", since there was no change in the data anyway. It is just that the message is very annoying for users.

5. If you add a space to the end of a text box (MySQL VARCHAR), it strips the trailing space from the value, but treats the record as dirty and needing update. Also, if you have code which changes one field based on a change in another field, but the target field already had that value, the same thing occurs. It also happens if you type the same value over the top of an existing field, or if you change it and then change it back before saving. It happens in both data view of a table and bound forms.


You *could* work around the problem by either checking whether any data is different and cancelling the record save event (which is a nasty solution).

My preferred method is to ensure there is always a change by creating a "LastUpdated" DATETIME field and setting it to Now() in the BeforeUpdate event. This means that you get around the problem as well as implementing a useful audit trail. Note that you have to ensure that any form based on a join of multiple tables updates the LastUpdated field on every table in the query. That could get a bit heavy in some cases, but it has to happen because any one of the tables could trigger the problem.


If someone wants to pick this up and look at it in details, it can be easily duplicated. Just create a table in MySQL 5.0 as follows:

CREATE TABLE `bugtable` (
  `BugId` int(11) NOT NULL auto_increment,
  `BugText` varchar(50) default NULL,
  `BugNumber` int(11) default NULL,
  `LastModified` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (`BugId`)

Set up a data source using MySQL ODBC Connector 3.51.

Link to the table in MS-Access 2003 (SP 3) and open the linked table.

Create a few record, refresh manually to see the TIMESTAMP change. Overtype a field with the same value or add a space to the bugtext field and save the (lack of) change to see the problem.

I am using the base JET 4 engine for 2003 (4.0.8618.0), and "No Locks" option (i.e. optimistic locking), but it also occurs with "Lock Records" option (pessimistic locking).

It may occur with other versions of everything too - not sure how specific it is.


I am happy to hear directly from anyone who can help with this or has a better work-around. It seems like many people have found the problem but been unable to isolate it.  It can easily be confused with issues with the setup of the TIMESTAMP field, multiple TIMESTAMP fields, Date vs Date/Time conversions, Null boolean issues, etc. which are all separate problems. It is not specific to the example table above, so it's not a problem with the syntax of the CREATE statement which is a dump of the table done by Heidi SQL 3.0.
  • 3
  • 2
1 Solution
One less complicated work around may be to create a boolean field specifically for the purpose of changing it's value so that something is in fact different in the record so that the TimeStamp works as intended.

Suppose the name of this field is BooChange

Then use the Form_Dirty Event to read...

Private Sub Form_Dirty(Cancel As Integer)
    Me.BooChange = Not Me.BooChange
End Sub

In so doing you're always assured something is in fact changed even if the value has not other purpose it is at least simple.

FirstStrikeSolutionsAuthor Commented:
That would be ok, but misses the (admitedly obscure) situtation that if you made a change, cancelled it and then made another change, it would change the value back to what it was before, causing the error. The date/time updated option I would be using would use the Form BeforeUpdate event and set the extra field to Now(), which should ensure that the value is different and only effects the change if the system actually gets to a save.

Both are valid work-arounds, but this idea presents a lot of work and risk of introducing bugs:
1. Adding one or two hidden fields to each form (one for each table) and the event code (up to 200 forms)
2. Adding an extra field to each table (104 of them)
3. Modifying every query to include the extra field from each table that may be updated by a form (240 to check although perhaps only 100 of them would need to be modified)
4. Requires adding this extra process into the application for Access-based back-ends, which is the majority of our installations, or having two versions of the system (which is almost out of the question).

In checking the web for solutoins, I saw someone mention setting a random number value - smae idea with the very small chance of picking the same number. This was actually in response to a different question but gave me the idea. Others said to update the timestamp field directly,which is a possibility.

If only I could find a parameter in the Access links, ODBC setup or MySQL to make it work.  The other option I thought of was to use a function on the BeforeUpdate event to run through all bound form controls and compare them the current recordset value. If they are all the same, it would silently cancel the update event. I am not sure if this will work, and in particular, I think it will work differently in Access than ODBC because they interract with the recordset differently, but it would mean only one call in each form. It may also raise an error which really defeats the purpose! Trying that will be my next step if I don't get a better idea in the next few days. Apart from no extra fields, it has the advantage of not doing extra updates. The down-side is that it may not work for multiple table query recordsets (there are one or two of them but they are central to the system).

Thanks for the idea. Did you manage to duplicate the issue at least? Just so I know I'm not missing something obvious that is specific to my setup or machine. I would be happy to hear from anyone who can replicate the problem. I am also trying to work out whether it is Access, ODBC or MySQL or a combination which cause the problem.
OK, I think I've come up with some ideas that might work for you but before I dig in too deeply I'd like to just make sure I'm aiming for the right target.  Recognizing that you'd like to have a solution that will...

1) Be absolutely bullet proof in that the approach by design will NEVER create a write conflict while...
2) Availing some method of storing a time stamp for every record in every table that is updated only when something within the form's recordset changes and...
3) the solution needs to be easy to implement, for example, there may be 200 forms or more that need to handle this painlessly in a very consistent way that can also be rolled out instantly across everything that currently exists and is just as easily included in anything that may yet be created.

I have an approach that will deliver all of the above but before we dig in would you like to add anything to the wish list.

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

FirstStrikeSolutionsAuthor Commented:

In fact, I don't need #2. I would be just as happy if the timestamp updated and the unchanged record was physically (but uselessly) saved each time. It is an exception case, not a regular thing now, as I have changed all code that sets control values automatically to only set them if they do not already have the same value. It is only when the user types the same value over a field.

It's just that MySQL seems to insist on not saving unsaved records and Access gets confused because it thought there was a save, so the timestamp should have been updated (it thinks). It appears to be a weakness in the way ODBC tries to handle record locks using the timestamp field.

Incidently, I have now implemented a routine that compares the control values to thei values of their bound recordset fields and cancels the save event if there is no difference for any of them. I also trap the error that this generates when doing an explicit record save. I then found that the error number is different in the Runtime version of Access 2003 too! This method is a bit clunky, but it's workable because it is just cut-and-paste of a one-line BeforeUpdate event handler onto all relevant forms.

Alternative ideas still welcome in case they are better or enable me to improve on this.
Just reviewing all my open questions and and found this still out there.  Sorry the really long delay.

If the issue is still an issue for you (I'd hope so since the question is still open) was serious about having an option.  I think it overcomes many of your concerns as well.

It involves adding some code to one of your modules and creating a Class Object that I called LastUpdate.

To make it work you need three things (aster you add the code to a module and create the class object below)

With each form you'd like to have a TimeStemp automatically updated for follow these steps...
    1) Insure that the recordsource has a field named TS for TimeStamp.  It should be a Date/Time field you want updated with the most current date and time when a record is saved.
    2) Place the following in the Form's OnLoad Event...
    3) Make sure the form has a module (Has Module = Yes)

You may be suprised that there is no code required beyind your form.  Yes that's right NO code so your previous concerns about having to go update the code of amny forms is now mute.

It works by instansiating an object that watches the form's BeforeUpdate event.  When it fires it updates your field TS with the latest date and time.  When you close the form in unloads the object.  What's nice about this approach is how transparent it is.  There's very little you need to do and it should take care of itself.

Sorry this question fell though the cracks.  Just let me know you need anything more.


Option Compare Database     'Module named basLastUpdate
Option Explicit
Global gColObj As New Collection
Function AutomationStart(frm As Form)
    Dim fld As DAO.Field
    With frm
        For Each fld In frm.Recordset.Fields
            If fld.Name = "TS" Then
                AddLastUpdated frm
                Exit For
            End If
        Next fld
    End With
End Function
Function AddLastUpdated(frm As Form)
    Dim obj As New LastUpdated
    Set obj = obj.Start(frm)
    gColObj.Add obj, CStr(frm.hwnd)
    Set obj = Nothing
End Function
Function CloseLastUpdated(strKey As String)
On Error Resume Next
    gColObj.Remove strKey
End Function
Option Compare Database   'Class Object Named LastUpdate
Option Explicit
Dim WithEvents mfrm As Form
Private Sub mfrm_BeforeUpdate(Cancel As Integer)
    mfrm.TS.Value = Now()
End Sub
Function Start(frm As Form) As LastUpdated
    Dim strEvent As String
    Set mfrm = frm
    If frm.BeforeUpdate <> "[Event Procedure]" Then frm.BeforeUpdate = "[Event Procedure]"
    strEvent = "=CloseLastUpdated(""" & CStr(frm.hwnd) & """)"
    If frm.OnClose <> strEvent Then frm.OnClose = strEvent
    Set Start = Me
End Function

Open in new window

Eileen MurphyIndependent Application DeveloperCommented:
Worked like a charm!!!

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now