MySQL
Access

MySQL to Access Converter

Move MySQL or MariaDB data into Microsoft Access for local copies, reporting tools, or legacy front-end maintenance. Schema conversion, type mapping, and optional two-way sync.

MySQL → Access migration usually means copying selected MySQL, MariaDB, Percona, or cloud MySQL tables into a Microsoft Access .mdb or .accdb file.

DBConvert handles the table-level move: it connects to MySQL, Amazon RDS / Aurora for MySQL, Azure Database for MySQL, or Google Cloud SQL; creates Access-compatible tables; maps field types; transfers rows; and can save the job for repeated exports. The review work is in Access file size, AutoNumber policy, large text and binary fields, Unicode text, date/time values, and MySQL SQL that Access cannot run.


What DBConvert does on this path: handles MySQL → Access as a repeatable desktop workflow:

  • Reads MySQL, MariaDB, Percona Server for MySQL, Amazon RDS / Aurora for MySQL, Azure Database for MySQL, and Google Cloud SQL for MySQL.
  • Writes a Microsoft Access .mdb or .accdb target file.
  • Maps tables, fields, indexes, primary keys, foreign keys, and supported views with type-mapping review.
  • Saves the job as a rerunnable session; DBSync keeps MySQL and Access aligned while both sides remain active.

What it does not do: MySQL stored procedures, triggers, events, users, grants, and application SQL are not translated into Access forms, reports, macros, or VBA.

Which tool: DBConvert or DBSync?

DBConvert for MySQL → Access

One-time migration or repeatable exports. Use it when Access is the target file for reporting, local analysis, QA samples, or a lightweight Office workflow.

DBSync for MySQL ↔ Access

Recurring exchange. Use it when the MySQL system remains active and the Access file needs periodic inserts, updates, or deletes. Review synchronization concepts.

Need more context? Compare DBConvert and DBSync side by side →

How DBConvert handles the MySQL → Access differences

DBConvert handles connection, object selection, type mapping, Access file creation, row transfer, and validation. MySQL server-side code and Access application design remain separate work.

Source and target shape

DBConvert reads local, hosted, or cloud MySQL-compatible sources and writes an Access .mdb or .accdb. Access is capped at 2 GB, so large sources should be filtered or split.

Generated keys

MySQL AUTO_INCREMENT columns need an Access AutoNumber or Number policy. Confirm next values before new Access inserts begin.

Large text and binary values

MySQL TEXT and LONGTEXT map to Access Long Text. BLOB values need an Access OLE Object or attachment-style policy based on how the file will be used.

Charset and collation

MySQL utf8mb4, collations, and case-sensitive values do not map one-for-one to Access. Test representative text, sorting, and unique indexes during the first export.

Application SQL boundary

DBConvert migrates tables, fields, supported views, indexes, and foreign keys. MySQL routines, triggers, events, grants, and MySQL-specific application SQL are not converted into Access forms, reports, macros, or VBA.

Type mapping checkpoints

MySQL Access Notes
INT / BIGINT / AUTO_INCREMENT Number / Large Number / AutoNumber Large Number requires modern Access .accdb.
DECIMAL(p,s) Decimal / Number Review precision and scale before reports use the Access file.
VARCHAR / TEXT / LONGTEXT Short Text / Long Text Check Access text length limits and Unicode behavior.
BLOB / LONGBLOB OLE Object / attachment policy Validate with real files, not only row counts.
DATETIME / TIMESTAMP Date/Time Check timezone assumptions from the MySQL application layer.
TINYINT(1), ENUM, SET, JSON Yes/No, Short Text, Long Text, lookup policy Pick a storage policy that matches application semantics.

Choosing the MySQL → Access route

Most projects are either an Access reporting export, a recurring local copy, or a temporary compatibility bridge.

Route Where it fits Where it falls short
DBConvert / DBSync You need a GUI workflow, Access file output, filters, type mapping review, saved sessions, or recurring synchronization. MySQL server-side code and Access application objects remain outside the row-copy workflow.
Access linked tables through ODBC Users only need to browse or report against live MySQL data from Access. This is not a conversion; it depends on drivers, network access, permissions, and live MySQL availability.
CSV export and Access import A few flat tables need to be moved once and relationships are not important. You lose schema metadata, constraints, type nuance, indexes, and repeatability unless you script them separately.
Custom ETL The Access file is only one output of a larger reporting or archival pipeline. You own driver setup, data shaping, Access size limits, retries, and validation.

Supported versions

  • MySQL 5.x, 8.x; MariaDB; Percona Server
  • Amazon RDS / Aurora MySQL, Azure Database for MySQL, Google Cloud SQL
  • MS Access .mdb (Jet) and .accdb (ACE) files
  • WorkGroups credentials and linked tables

Supported in this path

Source MySQL
Target Access
Microsoft Access MySQL MariaDB Percona Server for MySQL Amazon RDS for MySQL Amazon Aurora MySQL Azure Database for MySQL Google Cloud SQL for MySQL

Using MySQL to Access Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to MySQL source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to MySQL source database from DBConvert

MySQL source

Use the MySQL connection guide for local MySQL or MariaDB, or read from Amazon RDS / Aurora for MySQL, Azure Database for MySQL, or Google Cloud SQL for MySQL.

2

Connect to Access destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to Access target database from DBConvert

Access target

Write a fresh .mdb or .accdb file. Microsoft caps the file at 2 GB; pre-filter the export if the source is larger.

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options - pick tables, fields, indices, views.
  • Issue detection - the built-in checker flags integrity problems before migration starts.
  • Execute - commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI - rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3-5, software features, command-line mode, scheduler, and system requirements.

See all features