Solved

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

Posted on 2007-11-15
8
1,274 Views
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.

WORK-AROUNDS

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.

DUPLICATING 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`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1;

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.

SOLUTIONS

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.
0
Comment
Question by:FirstStrikeSolutions
  • 3
  • 2
8 Comments
 
LVL 16

Expert Comment

by:Rick_Rickards
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.

Rick
0
 

Author Comment

by:FirstStrikeSolutions
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.
0
 
LVL 16

Expert Comment

by:Rick_Rickards
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.

Rick
0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 

Author Comment

by:FirstStrikeSolutions
ID: 20380208
Rick,

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

Accepted Solution

by:
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...
        =AutomationStart([Form])
    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.

Rick


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

0
 

Expert Comment

by:Ei0914
ID: 37332910
Worked like a charm!!!
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Access 2010 ComboBox Requery Not Working 17 24
Loop within Select Case 3 26
Access MDB/PDF 21 32
mysql left join sentence 7 22
As a database administrator, you may need to audit your table(s) to determine whether the data types are optimal for your real-world data needs.  This Article is intended to be a resource for such a task. Preface The other day, I was involved …
Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
In Microsoft Access, learn how to use Dlookup and other domain aggregate functions and one method of specifying a string value within a string. Specify the first argument, which is the expression to be returned: Specify the second argument, which …
With Microsoft Access, learn how to start a database in different ways and produce different start-up actions allowing you to use a single database to perform multiple tasks. Specify a start-up form through options: Specify an Autoexec macro: Us…

747 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now