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

Posted on 2007-11-15
Last Modified: 2013-12-25
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.
Question by:FirstStrikeSolutions
  • 3
  • 2
LVL 16

Expert Comment

ID: 20305550
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.


Author Comment

ID: 20307048
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.
LVL 16

Expert Comment

ID: 20379067
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.

Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.


Author Comment

ID: 20380208

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.
LVL 16

Accepted Solution

Rick_Rickards earned 500 total points
ID: 21939319
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


Expert Comment

ID: 37332910
Worked like a charm!!!

Featured Post

Migrating Your Company's PCs

To keep pace with competitors, businesses must keep employees productive, and that means providing them with the latest technology. This document provides the tips and tricks you need to help you migrate an outdated PC fleet to new desktops, laptops, and tablets.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Phishing attempts can come in all forms, shapes and sizes. No matter how familiar you think you are with them, always remember to take extra precaution when opening an email with attachments or links.
It’s the first day of March, the weather is starting to warm up and the excitement of the upcoming St. Patrick’s Day holiday can be felt throughout the world.
In Microsoft Access, when working with VBA, learn some techniques for writing readable and easily maintained code.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

830 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question