http://www.packtpub.com/article/exporting-data-from-ms-access-2003-to-mysql by Dr.

Jay Krishnaswamy | July 2009 | PHP Most businesses use a software mix in their IT arsenal that makes business sense to them. Because of this, often they have to migrate a part, or whole of their data from one software program to another. In this article by Dr. Jay Krishnaswamy, the built-in method of exporting tables in Microsoft Access is explored to take a table in Microsoft over to MySQL, the open source database product that changed hands recently. This article steps you through the process with a number of screen shots to guide you along the way.

Introduction
It is assumed that you have a working copy of MySQL which you can use to work with this article. The MySQL version used in this article came with the XAMPP download. XAMPP is an easy to install (and use) Apache distribution containing MySQL, PHP, and Perl. The distribution used in this article is XAMPP for Windows. You can find documentation here. Here is a screen shot of the XAMPP control panel where you can turn the services on and off and carry out other administrative tasks.

You need to follow the steps indicated here: 1. Create a database in MySQL to which you will export a table from Microsoft Access 2003 2. Create a ODBC DSN that helps you connecting Microsoft Access to MySQL

3. Export the table or tables 4. Verify the exported items

Creating a database in MySQL

You can create a database in MySQL by using the command 'Create Database' in MySQL or using a suitable graphic user interface such as MySQL workbench. You will have to refer to documentation that works with your version of MySQL. Herein the following version was used. The next listing shows how a database named TestMove was created in MySQL starting from the bin folder of the MySQL program folder. Follow the commands and the response from the computer. The Listing 1 and the folders are appropriate for my computer and you may find it in your installation directory. The databases you will be seeing will be different from what you see here except for those created by the installation.

Listing 1: Login and create a database

Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:Documents and SettingsJayaram Krishnaswamy>cd C:>cd xamppmysqlbin C:xamppmysqlbin>mysql -h localhost -u root -p Enter password: ********* Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 2 Server version: 5.1.30-community MySQL Community Server (GPL) Type 'help;' or 'h' for help. Type 'c' to clear the buffer. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | cdcol | | expacc | | mengerie | | mydb | | mysql | | phpmyadmin | | test | | testdemo | | webauth | +--------------------+ 10 rows in set (0.23 sec) mysql> create database TestMove; Query OK, 1 row affected (0.00 sec) mysql> show databases;

+--------------------+ | Database | +--------------------+ | information_schema | | cdcol | | expacc | | mengerie | | mydb | | mysql | | phpmyadmin | | test | | testdemo | | testmove | | webauth | +--------------------+ 11 rows in set (0.00 sec) mysql>

The login detail that works error free is shown. The preference for host name is localhost v/s either the Machine Name (in this case Hodentek2) or the IP address. The first 'Show Databases' command does not display the TestMove we created which you can see in response to the 2nd Show Databases command. In windows the commands are not case sensitive.

Creating an ODBC DSN to connect to MySQL

When you install from XAMPP you will also be installing an ODBC driver for MySQL for the version of MySQL included in the bundle. In the MySQL version used for this article the version is MySQL ODBC5.1 and the file name is MyODBC5.dll. Click Start | Control Panel | Administrative Tools | Data Sources (ODBC) and open the ODBC Data Source Administrator window as shown. The default tab is User DSN. Change

to System DSN as shown here.

Click the Add... button to open the Create New Data Source window as shown.

Scroll down and choose MySQL ODBC 5.1 Driver as the driver and click Finish. The MySQL Connector/ODBC Data Source Configuration window shows up.

You will have to provide a Data Source Name (DSN) and a description. The server is the localhost. You must have your User Name/Password information to proceed further. The database is the name of the database you created earlier (TestMove) and this should show up in the drop-down list if the rest of the information is correct. Accept the default port. If all

information is correct the Test button gets enabled.

Click and test the connection using the Test button. You should get a response as shown.

Click the OK button on the Test Result window. Click OK on the MySQL Connector/ODBC Data Source Configuration window. There are a number of other flags that you can set up using the 'Details' button. The defaults are acceptable for this article.

You have successfully created a System DSN 'AccMySQL' as shown in the next window. Click OK.

Verify the contents of TestMove

The TestMove is a new database created in MySQL and as such it is empty as you verify in the following listing.

Listing 2: Database TestMove is empty

mysql> use testmove; Database changed mysql> show tables; Empty set (0.00 sec) mysql>

Choosing an Open Source CMS: Beginner's Guide

Find the best CMS and start working with it to create web sites, blogs, communities, e-commerce sites, and intranets

Export the Employees table from MS Access to TestMove

Open the Northwind.mdb (or any other mdb file) file as shown in the next figure.

Highlight the Employees table and make a right click to bring up a drop-down menu as

shown.

Click on Export to open the Export Table 'Employees' To... window. Click on the Save as type drop-down to reveal the various file types that you can export to as shown.

Click on ODBC Sources the Export window pops-up as shown.

Click OK. This opens the Select Data Source window. Click on the Machine Data Source tab to show the various available DSN's. You will notice the AccMySQL created earlier.

Choose AccMySql and click OK. The program returns you to MS Access's Northwind database without giving you an indication about the success/failure of the export. If there is an error it however gives a error message.

Verifying and accessing exported table

Now go back to the DOS screen. I assume you have not closed down the mysql > prompt. Enter commands as shown in the listing.
mysql> use testmove Database changed mysql> show tables; +--------------------+ | Tables_in_testmove | +--------------------+ | employees | +--------------------+ 1 row in set (0.00 sec) mysql>

Now you can see that the Employees table has entered the TestMove database in MySql. Probe a little further by entering a select statement to see how much of the data has come in.
mysql> use testmove Database changed mysql> show tables; +--------------------+ | Tables_in_testmove | +--------------------+ | employees | +--------------------+ 1 row in set (0.00 sec) mysql> Select * from Employees; +------------+-----------+-----------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------+-----------+ | EmployeeID | LastName | FirstName | Title | TitleOfCourtesy | BirthD ate | HireDate | Address | City | Region | PostalCode | Country | HomePhone | Extension | Photo | Notes | ReportsTo | +------------+-----------+-----------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------+-----------+ | 1 | Davolio | Nancy | Sales Representative | Ms. | 1968-1 2-08 00:00:00 | 1992-05-01 00:00:00 | 507 - 20th Ave. E. Apt. 2A | Seattle | WA | 98122 | USA | (206) 555-9857 | 5467 | EmpID 1.bmp | Education includes a BA in psychology from Colorado State University. She also co mpleted "The Art of the Cold Call." Nancy is a member of Toastmasters International.| 2 | | 2 | Fuller | Andrew | Vice President, Sales | Dr. | 1952-0 2-19 00:00:00 | 1992-08-14 00:00:00 | 908 W. Capital Way | Tacoma | WA | 98401 | USA | (206) 555-9482 | 3457 | EmpID2.bmp | Andrew received his BTS commercial and a Ph.D. in international marketing from the University of Dallas. He is fluent in French and Italian and reads German. He joined the company as a sales representative, was promoted to sales manager and was then named vice president of sales. Andrew is a member of the Sales Management Roundtable, the Seattle Chamber of Commerce, and the Pacific Rim Importers Association. | NULL | | 3 | Buchanan | Steven | Sales Manager | Mr. | 1955-0 3-04 00:00:00 | 1993-10-17 00:00:00 | 14 Garrett Hill | London | NULL |

SW1 8JR | UK | (71) 555-4848 | 3453 | EmpID5.bmp | Steven Buchanan graduate d from St. Andrews University, Scotland, with a BSC degree. Upon joining the company as a sales representative, he spent 6 months in an orientation program at the Seattle office a nd then returned to his permanent post in London, where he was promoted to sales manager. Mr. Buchanan has completed the courses "Successful Telemarketing" and "International Sale s Management." He is fluent in French. | 2 | | 4 | Suyama | Michael | Sales Representative | Mr. | 1963-0 7-02 00:00:00 | 1993-10-17 00:00:00 | Coventry House Miner Rd. | London | NULL | EC2 7JR | UK | (71) 555-7773 | 428 | E mpID6.bmp | Michael is a graduate of Sussex University (MA, economics) and the University of California at Los Angeles (MBA, marketing). He has also taken the courses "Multi-Cultural Selling" and "Time Management for the Sales Professional." He is fluent in Japanese and can read and write French, Portuguese, and Spanish.| 3 | +------------+-----------+-----------+-------------------------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------+-----------+ 4 rows in set (0.00 sec) mysql>

The output is not particularly pretty but you can see that the data has come in. The next figure shows the same query run in MySQL Workbench a graphic tool used in querying and modeling MySql databases.

Summary
The article described the procedure to create an ODBC DSN for connecting to a MySQL Database. The article also described the process of copying data in an MS Access database to MySQL.

Migration Issues
According to a recent survey, over 20% of MySQL users plan to migrate a Microsoft Access applications to MySQL over the next 12 months. However there are few documents available that describe best practices for performing such a migration. This document summarizes discussion from the MS Access Migration session at the 2007 MySQL User Group meeting in California. That session brought together a number of MySQL users with a goal of identifying key success factors for moving MS Access applications to MySQL. Because MS Access applications were often created in an ad hoc fashion, migration can pose particular challenges. MySQL Users reported two common migration problems: Data migration issues: MS Access data conversion is often complicated by poor schema design and even low data quality. Application migration issues: MS Access applications often

contain logic or design errors in their forms and reports, making them impossible to convert automatically. The group consensus was that a successful migration path has three fundamental tasks: 1. Rebuild the schema: create a new schema in MySQL that reflects SQL best practices rather than trying to simply recreate the Access schema in MySQL 2. Clean the data: extract the data from the Access database, cleanse the data, then import the data into the new MySQL schema 3. Rewrite the application: rebuild the Access application using web development tools like php or ActiveGrid

Motivation for MS Access to MySQL Migration

Access is the default choice of departmental developers with moderate technical skills. Often, Access applications are built by downloading corporate data to Excel, converting the spreadsheet to an Access database, then adding ad hoc forms and reports. Because they grow organically, these applications usually lack formal requirements. MySQL users cited increasing pressures for companies to migrate Access applications:

Low data quality: Access applications often have out-of-date corporate data or corrupt data based on poorly defined schemas Poor security: Access applications do not integrate with corporate security and do not allow advanced security such as role-based access controls Limited manageability: Access applications can not be centrally managed by IT No web-based distribution: Access applications cannot be accessed over the web SOX compliance: Access applications are often identified in corporate audits as a significant source of risk.

Addressing Data Migration Issues

MySQL provides a data migration tool, the MySQL Migration Tool. However, this tool is only as good as the underlying schema and data of the database to be converted. Because schema and data quality issues are so pervasive with Access, MySQL users often find it easier to rebuild the data schema in MySQL from scratch. The two most common data quality issues with Access migration are: Access data schema is not SQL-ready: Access developers are typically not familiar with the basics of SQL schema design. MySQL DBAs report that Access schemas often resemble an Excel spreadsheet more than a classic SQL schema. For example, the schema may lack primary, foreign key, and referential integrity constraints.

Access data is not clean: in part because the tables were not defined rigorously, the data in Access databases is often corrupt. One MySQL user reported finding text strings in fields which were meant to be date fields for geotechnical data.

Addressing Application Migration Issues

Porting the data from Access to MySQL only addresses part of the problem. There is still the issue of what to do with the forms and reports associated with the Access application. In addition, it is often possible to consolidate multiple Access applications into a single web application. Similarly, it is often possible to consolidate several Access forms into a single, well-designed web page. While is possible to use ODBC to access MySQL data from Access, most MySQL users choose to rewrite the application. The reasons for rewriting Access applications include:

Quality issues: given that the original MS Access app was written by a nonprogrammer, I dont even want the logic moved I dont trust it. Desire to make application web-based: most MySQL users would prefer to migrate legacy MS Access applications to more robust web architectures Security requirements: MySQL users often want to add enterprise security features like Siteminder/LDAP authentication and role-based access controls

Although there are tools available that automate the conversion of a MS Access application to Java, MySQL users reported little success with automated conversion. Instead, the preferred approach is to port MS Access applications using a coding language like PHP or a web 2.0 visual builder like ActiveGrid.

Rapid Application Development For MySQL - ActiveGrid

MySQL users recognize that the process of migrating MS Access applications to MySQL often requires rebuilding the application. They are very interested in any tools that can accelerate the application development process. ActiveGrid is a web 2.0 visual builder for MySQL that greatly simplifies the task of migrating an MS Access application. Many MS Access application developers (and MySQL DBAs for that matter!) prefer a visual approach to building applications and have little interest in complex Java frameworks. ActiveGrid is ideal for these developers. The following table shows the similarities between the MS Access and ActiveGrid visual development tools: Building an ActiveGrid application is as simple as following a three step process based on the Model-View-Controller (MVC) design pattern:

1. Define the model. The model defines the data used in the application, including database tables and relationships between tables. The developer specifies this information by importing an existing database schema or using a visual data editor. 2. Create the views. The view describes the web pages displayed by the application. ActiveGrid can create default Ajax web pages based on the database schema, or the developer can create new web pages using a visual screen builder. 3. Build the controller(s). The controllers manage actions within the application, including navigation between pages and invoking data, security and web services. The developer can define new actions using a visual action editor that call web services or custom code modules written in Java or Python.

A Process for MS Access Migrating

The consensus of MySQL users is that automated conversion tools for MS Access do not work. For example, tools that translate existing Access applications to Java often result in 80% complete solutions where finishing the last 20% of the work takes longer than starting from scratch. Instead, the best practice for Access migration is to rebuild the schema, cleanse the data and then rewrite the application. Although this is time intensive, it is the only way to ensure that the resulting application is of sufficient quality to be maintainable. This lays out a step-by-step process to migrate an MS Access application to MySQL: 1. Rebuild the schema: create a new schema in MySQL that reflects SQL best practices rather than trying to simply recreate the MS Access schema in MySQL. Ensure proper definitions for the following elements 1. Primary keys 2. Indexes for common search and join columns 3. Foreign keys for all relationships, along with cardinality constraints and delete propagation constraints 4. Default values for columns 5. Null-allowed columns 6. Views 2. Clean the data: extract the data from the MS Access database, using the MySQL Migration tool or a simple .CSV export. Before importing the data, perform data cleansing: 1. Ensure primary key uniqueness 2. Ensure referential integrity: check that primary key exists for all foreign keys, ensure foreign key uniqueness for 1..1 relationships 3. Ensure that non-null columns have a value 4. Ensure that data types agree, particularly for date, integer, decimal data types 5. Import cleansed data into new MySQL schema 3. Rewrite the application: review the forms, reports and queries of the Access application and re-design them rebuild the application forms and reports using web tools rather than trying to convert the existing application and scripts.

1. Import MySQL data schema into visual builder tool such as ActiveGrid 2. Create new web pages that provide graphical interface for application using the ActiveGrid page editor 3. Define actions that provide needed functionality for application using the ActiveGrid action editor, custom Java or Python code, or web services. In summary, best practices for Access to MySQL migration require careful migration of data to a new schema along with a requirements-driven rebuilding of the application forms and reports using web-based development tools. MySQL is an increasingly attractive database solution for companies trying to improve the security and data quality of their departmental applications. However a successful migration from Access requires pairing MySQL with a web development tool.

Other resources
There are a number of additional resources on the web describing MS Access to MySQL migrations: Dual-Master MySQL 5 Replication Done Right MySQL replication is the most flexible way to deal with scalability. If not done right, however, replication can result in disaster. The most common problem with replication is primary key collision. Primary key collision involves two MySQL servers creating table rows containing different data, but the same primary key. When this happens replication stops. With replication stopped, the difference between the data on the servers grows. At some point the weirdness gets noticed. Then begins the painful process of recovery, of trying to weave masses of conflicting data into a whole. In this tutorial, we'll outline, step-by-step, how to avert disaster by creating a dual master MySQL replication setup configured to avoid primary key collision. We'll call the two MySQL servers Server A and Server B. In a dual master setup each server functions as both a master and a slave to the other server. If you run into any problems, feel free to visit our forum and share details! Problems? Neo Code Software Can Help! What's 10 - 3? First Name Last Name Email

Preparing For Replication

The first thing to do when getting ready for replication is to make sure that the database on each server is in the same state. If in doubt, create a dump of one server's version of the database then import it into the other server. Example of A MySQL Dump: Server A command line> mysqldump -u <mysql user> -p<mysql password> -c <database name> > <filename of dump> (copy dump file to Server B) Server B command line> mysql -u <mysql user> -p<mysql password> -D <database name> < <filename of dump> The next thing to do is create a "slave user" on each of the two servers. These users are used by MySQL for the slave to master connection and need to be given specific privileges. You can name them whatever you'd like. Creating A Slave User: Server MySQL command line> USE mysql; Server MySQL command line> INSERT INTO user (Host, User, Password, Select_priv, Reload_priv, Super_priv, Repl_slave_priv) VALUES ('<Hostname/IP>', '<slave user>', password('<slave password>'), 'Y', 'Y', 'Y', 'Y'); Server MySQL command line> FLUSH PRIVILEGES;

Configuring The MySQL Servers

The next thing to do is configure each MySQL server. You'll need to know the IP address of each server. On each server you'll need to edit your MySQL Server configuration file (usually called my.cnf or my.ini). Below is what needs to be added to the configuration for Server A: server-id = 1 replicate-same-server-id = 0 auto-increment-increment = 2 auto-increment-offset = 1 master-host = <IP address of Server B>

master-user = <slave user> master-password = <slave password> master-connect-retry = 60 replicate-do-db = <database name> log-bin = C:\mysql\log\log-bin.log # change this to a path/name appropriate to your system binlog-do-db = <database name> Below is what needs to be added to the configuration for Server B: server-id = 2 replicate-same-server-id = 0 auto-increment-increment = 2 auto-increment-offset = 2 master-host = <IP address of Server A> master-user = <slave user> master-password = <slave password> master-connect-retry = 60 replicate-do-db = <database name> log-bin= C:\mysql\log\log-bin.log # change this to a path/name appropriate to your system binlog-do-db = <database name> After making the changes to your configuration, restart the two servers. Check your MySQL error logs for any problems. A warning message will likely recommend that you specify the name of your relay log in your server configuration. To avoid future problems, do this! A relay log, for those that are wondering, is simply a local echo of data read from the master's log. Note: The two MySQL configuration variables that prevent key collisions are autoincrement-increment and auto-increment-offset. The value of auto-increment-increment should be set to N, where N is equal to the number of servers in the replication setup (in this case two). The auto-increment-offset and server-id configuration variables should be set as consecutive integers (in this case 1 and 2).

Synchronizing the Servers

The last thing needed to set up replication is the synchronization of the servers. In the MySQL command line of each server, issue the "slave stop" command then the "show master status" command. This will give you infomation that you'll need to manually provide to the other server. This information is needed to "synchronize" the two servers.

Next, on each server enter the command below into the MySQL command line of each server: Server MySQL command line> CHANGE MASTER TO MASTER_HOST='<master's IP>', MASTER_USER='<slave user>', MASTER_PASSWORD='<slave password>', MASTER_LOG_FILE='<master's log file name>', MASTER_LOG_POS=<master's log file position>; Once you've entered the above command, issue the "start slave" command on both servers. Replication should now be working! To confirm that replication is working, first issue the "show slave status" command on both servers. Both "Slave_IO_Running" and "Slave_SQL_Running" should be "YES". If both aren't "YES", you'll need to reset replication.

Resetting Replication
It doesn't take much for replication to go out of sync. A simple network interruption to one server can effectively halt two-way replication if data gets written during the interruption. It makes sense to learn how to reset replication before something goes wrong. A network outage can be simulated by unplugging one of the MySQL servers from the network. While one server is unplugged, try inserting rows to both. This will generally disrupt replication even though, after restoring network connectivity, the slave status of each server may look normal. To reset replication, shut down both servers, delete their relay logs, and synchronize the servers (as outlined in the previous section). Deleting the relay logs will cause each server to re-read from their master.

Testing
Before putting a replication setup into production, be sure to thoroughly test it. Primary keys generated on Server A should always be odd numbers, while those generated on Server B should always be even. Have fun!