Question

I am looking for a way to manage syncronization between an Access mdb file for an application, and a MySQL schema containing a copy of the same tables. This arose from the fact that the application doesn’t support MySQL as a backend, but I am looking for a way to utilize MySQL for other in-office applications using the data the first application generates.

Some givens:

1> We cannot abandon the first application, and it’s only compatible with Microsoft SQL Server as a backend server to house data.

2> We are not against using Microsoft SQL server, but the licensing cost is a big concern – as well as rewritting some other Access applications written to use linked tables and seperate mdb files.

3> The database server should be ‘PHP friendly’ for a future expansion project for an internal corporate intraweb.

4> No data needs to be, nor should be allowed to be, accessed from outside the corporate network.

I hope I am not being too obscure, but I don’t want to break confidences either – so I am trying to walk a pretty tight rope. If anyone can help, I’d greatly appreciate it.

Answer 1

Synchronizing two databases is very, very complicated if both databases need to be updatable. If one is a slave of the other, it’s not nearly as difficult. I have more than once programmed just this kind of synchronization using Access, once with an MDB on a web server that had to be synched with a local data MDB (to incorporate data edited on the website; no edits went back to the website, so one-way synch, but still the need to merge edits on the non-web side), as well as once programming a synch between MySQL on a website and Access in a master (MySQL) / slave (Access) relationship.

On the website, you program a dump of data for each table to a text file. It’s helpful to have timestamp fields in the MySQL tables so that you know when records were created and updated. This allows you to select which records to dump since the last data dump (which makes the synchronization of data on the Access side much simpler).

The way I programmed it was to then import the text files into staging tables that were indexed appropriately and linked to the front-end Access app. Once the data dumps are imported into the staging tables, you then have three tasks:

1. find the new records and append them to the Access data store. This is easily done with an outer join.

2. deal with the deletions. I’ll discuss this later, as it’s, well, complicated.

3. deal with updated records. For this, I wrote DAO code that would write column-by-column SQL statements.

Something like this:

UPDATE LocalTable SET LocalTable.Field1 = DownloadTable.Field2, LocalTable.Updated = DownloadTable.Updated WHERE LocalTable.Field1 <> DownloadTable.Field2 

Now, obviously, the WHERE clause has to be a bit more complicated than that (you have to deal with NULLs, and you have to use criteria formatted appropriately for the data types, i.e., with ” and ## for text and dates, respectively, and no delimiters for numeric data), but writing the code to do that is pretty easy.

Skeleton code looks something like this:

  Dim db As DAO.Database   Dim rsFields As DAO.Recordset   Dim fld As DAO.Field   Dim strSQL As String    Set rsFields = db.OpenRecordset('SELECT TOP 1 Field1, Field2, Field3 FROM LocalTable;')   For Each fld in rsFields     [write your SQL statement and execute it]   Next fld   Set fld = Nothing   rsFields.Close   Set rsFields = Nothing   Set db = Nothing 

Now, as I said, the complicated part is writing the WHERE clause for each SQL statement, but that’s pretty easy to figure out. Also, note that in your rsFields recordset (which is used only to walk through the fields you want to update) you want to include only the fields that are updatable, so you’d leave out the CREATED field and the PK field (and any other fields that you don’t want to update).

Now, for the DELETES.

You might think it’s a good idea to simply delete any record in the local table that’s not in the remote table. That works fine if it really is a slave database, but so often what is originally a slave ends up getting its own edits. So, in that case, you need to not delete records from the master MySQL database, and instead have a DELETE flag that marks records deleted. You could have different varieties of logic that could clean the deleted records out of the master database (e.g., if you’re using date stamps in the records, you could delete all records flagged DELETED with LastUpdated timestamp that is <= the last time you dumped the data; alternatively, you could have the Access app send a text file up to the server with a list of the records that have been successfully deleted from the Access data store). If there are edits in the Access data store, then you’ll need some logic for dealing with an edit there on a record that was deleted from the MySQL ‘master’ database.

In summary:

If you have a true master/slave relationship, it’s fairly trivial. If you really wanted to do it by brute force, you’d just dump the entirety of all the MySQL data tables to text files, delete all the records in your Access data store and import the text files.

I would tend not to do that, as the first time you need to depart from the pure master/slave relationship, you’re hosed and have to rewrite everything from scratch.

The outline I gave above will work very cleanly for master/slave, but will also work well if you have a few fields that are private to the ‘slave’ database, or data that exists in the slave and not in the master (which is the situation I was working with).