MS Access and MySQL

September 15, 2008

(By Ian Andrew from Canberra with a little bit of help from Garry Robinson.)

Setting the Scene

Last year we took on an elderly, undocumented Access 97 database linked to a MySQL back-end. The task was to fix existing problems, upgrade to Access 2007 and Vista, and bring the functionality in line with current business practices. It would involve an independent re-build (mainly off site) so that existing operations could continue unhindered.

Concurrent upgrading changes weren’t ideal: when a problem arose, we had to work out whether it was due to a flaw in the original database, or 97 to 2007 differences, or some aspect of the Access to ODBC driver to MySQL linkage. But we had no choice and with Allen Browne’s comprehensive list of Access 2007 issues, we marched on.

Something New

MySQL was completely new to us. Moreover, while we knew an updated back-end would be needed, we didn’t know whether it should remain MySQL or change to Access. So we wanted to keep both options open.

An early problem, before we could start work off-site, was that there were two sorts of links from the front-end to MySQL tables. In the first case, the tables were linked via the MySQL ODBC driver: we could re-link to the development back-end and queries, forms/reports and VBA references continued to function. In the second case, pass through queries and ADO connections referred directly to the on-site MySQL server and database: these would not work off-site. To simplify matters, the latter were changed to normal queries and DAO references to the linked tables.

Finding Out About MySQL

Our aim was to set up an off-site copy of the working MySQL database, an Access version of the same back-end, and a front-end that could link to either.

So how to do it. We started with Google. ‘MS Access’ and ‘MySQL’ found a range of references: a non-exhaustive list of tools and advice we found useful follows:

On with the Story

As it’s unlikely you’ll find yourself in our situation, for the rest of this narrative we’ll assume you are an Access developer who wants to migrate an Access back-end to a local MySQL server for development and testing purposes. You’ll maintain your own solution and are happy to use the Community Server (free).

Step 1 – Install MySQL

Go to http://dev.mysql.com/downloads/ to download the server, MySQL GUI tools and MySQL ODBC driver. You have a choice of server: 5.0, 5.1 or 6.0 (Alpha). We’ve used 5.1 and 6.0 without any problems. Then install all three.

Points to note during installation:

• Your firewall will have to be set to allow connections through Port 3306.
• We chose to run MySQL as a service (command line is an option).
• MySQL installation defaults to username/login = root and server = localhost.
• MySQL offers a choice of storage engine/table type – the main ones are MySAM or InnoDb. The latter seems more like Access, with transactions and foreign keys, so at the moment we’re leaning that way.
• User and security options are available. Don’t forget to record any passwords.

We also installed Bullzip Access to MySQL and Dreamcoder for later use.

Step 2 – Move Tables from Access to MySQL

Either use Bullzip to transfer back-end tables to MySQL, or open your database and export the table via ODBC.

Points to note:

• MySQL does not recognise Access functions used as field defaults (eg Now() and Date() in Date/Time fields): they may be dropped or the table rejected. Recommend you remove them before transfer/export.
• Access autonumber fields are not identical to MySQL auto_increment. Bullzip will convert on transfer, ODBC will not.
• Access data types will be converted to similar MySQL data types. However, there is a greater range in MySQL (refer to the Manual) and you may wish to change them later.
• An Access ‘ole object’ becomes a ‘blob’ in MySQL. Due to an OLE Server problem, we changed blobs to longtext (memo in Access).

Step 3 – Modify MySQL Tables (Columns)

Open Dreamcoder (easier to use at this stage) or MySQL Administrator (one of the GUI tools). If you are used to SQL Server, think of these as the Enterprise or SQL server management studio express interfaces.

Connect to the transferred/exported database.

Open each table in turn and check:

• autonumber fields(columns) are auto_increment.
• There is a primary key (one or more fields) for each table (in Dreamcoder, Create – New Constraint). Otherwise, you’ll have to nominate when linking and/or the linked table will not be updateable.
• Field defaults are correct. We checked for consistency with front-end data entry defaults.
• Whether Null should be allowed or not.
• Data types are as desired.
• There is a timestamp field with default current_time (usually the last field in the table).

Step 4 – Setup Your MySQL Backup Systems

Open MySQL Administrator and back up your MySQL database. This will save the schema and data to a .sql file. If you want to set up the database on another computer, install a MySQL server on that machine then restore a copy of the .sql file to the new server.

Step 5 – Link Front-End to MySQL

Open your Access front-end. If you are already linked to an Access backend, you can’t use the linked table manager to change to an ODBC data source. So delete the links to the Access backend and link, via ODBC, to the MySQL back-end. Similarly, once linked to an ODBC data source, the linked table manager offers only a choice of ODBC sources.

When setting up the ODBC data source, in ODBC Configure – Advanced – Flags1, tick Return Matching Rows and Allow Big Results.

Performance

Observations so far:

• Access 97 with a MySQL backend was significantly faster than Access 2007 with the same backend.
• The original combo and list box row sources used the row source query builder. For some reason replacing them with user-created queries improved speed dramatically.
• In the current configuration, Access 2007 with an Access backend is a little faster than with the MySQL backend.

Our next step is to test the effect on performance of using Access pass through queries and MySQL queries (views).

Questions and Answers

Did you need any special skills to work with MySQL?

No. Access developer experience plus the MySQL information available online and from the Manual was more than enough to get us started on this migration project. If we go beyond small-business use, no doubt we’ll be attending MySQL training sessions.

Why migrate to MySQL?

Listed benefits include:

• Cost (free).
• Open source.
• Scalability (not subject to Access’s 2GB limit).
• Heavy duty multiple user capability.
• Security (secure password and privilege system).
• Portability (Windows, Linux, …) for your back-end data
• Connectivity (Access front-end, or accessible over the Web using a range of client programs). Note that you had better discuss security with a web professional before doing this.

Why stick with Access?

• Easier to develop and maintain because you only need to know the one tool.

Conclusion

The client was happy with his MySQL back-end and we’ve been able to re-develop it for him.

At its current size an Access backend also would be suitable, but there is no major benefit to be gained by developing it.

We have learnt a new server/database system that may be useful in developing future applications.

About my colleague

Ian Andrew is developer from NSW in Australia that has been helping me out for the last two years. In that time, Ian has worked with airlines, mining companies and a qualitative research firm and has racked up good Access solutions that are easy to use.

» See All Articles by Columnist Garry Robinson