SQL Server
Access

SQL Server to Access Converter

Move SQL Server data into Microsoft Access for local copies, offline use, or maintaining Access front-end applications. Schema conversion, type mapping, and optional two-way sync.

SQL Server to Access moves data from a server engine into a single-file desktop database - .mdb (Jet) or .accdb (ACE), capped at 2 GB per file.

The row copy is the easy part; reshaping a server schema to fit a desktop file is where the work lives.

What DBConvert does on this path: handles the SQL Server → Access extract as a repeatable desktop workflow:

  • Reads SQL Server, SQL Server Express, Azure SQL Database, or Amazon RDS for SQL Server.
  • Writes a new .mdb (Jet) or .accdb (ACE) file with schema, rows, primary keys, non-unique indexes, and relationships.
  • Pre-load type mapping review and explicit identity-insert handling so existing SQL Server identity values land in matching Access columns instead of being renumbered.
  • Saved sessions, optional per-table row filters, and a CLI for scheduled re-runs.

What it does not do: T-SQL stored procedures, functions, views with T-SQL features, triggers, and CLR routines are not converted to Access saved queries or VBA - server-side logic stays on the SQL Server side or must be reimplemented as Access queries.

Which tool: DBConvert or DBSync?

DBConvert for SQL Server → Access

One-time extract. Use it when you need a self-contained Access file built from a SQL Server subset for local reporting, an offline copy, or seeding a fresh Access front-end.

DBSync for SQL Server ↔ Access

Repeat refresh. Use it when the same Access file must be rebuilt or topped up on a schedule from the SQL Server backend, or when small Access edits should flow back into SQL Server under explicit ownership rules.

Both products run locally as Windows desktop tools. They write to a real Access file rather than ODBC-linking tables - that distinction matters when the file has to leave the SQL Server network.

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

How DBConvert handles the SQL Server → Access differences

SQL Server carries server-side assumptions that an Access file cannot hold - 2 GB file cap, weaker types, flat namespace. DBConvert handles those in the wizard with sensible defaults that you can review or override per table; T-SQL procedural code is outside the migration tool.

Type mapping

SQL Server type Access default
BIGINTDecimal (Access Long Integer is 32-bit)
datetime2 / datetimeoffsetDate/Time (second-level precision)
NVARCHAR(MAX)Long Text (Memo)
UNIQUEIDENTIFIERReplication ID (GUID)

Each mapping is overridable per column.

Access file size cap

Microsoft caps .accdb / .mdb files at 2 GB minus system objects. DBConvert lets you pre-filter the export (per-table WHERE clause: date range, branch, tenant) in the wizard so a large SQL Server source produces an Access file that opens cleanly.

Identity columns and indexes

Maps SQL Server IDENTITY columns to Access AutoNumber and sets the next-value seed above the loaded maximum key value - so the next Access-side insert does not collide. Primary keys and non-unique indexes recreate cleanly; filtered indexes and full-text indexes are not supported in Access and are dropped on the target.

Identifier cleanup

Rewrites schema-qualified SQL Server object names (dbo.Customer) into Access's flat namespace, escapes reserved Access keywords, and normalizes names with spaces or punctuation - pick the rename policy in the wizard.

Access Database Engine and bitness

Writes to .accdb through Microsoft Access Database Engine 2016 Redistributable (Microsoft.ACE.OLEDB.16.0) or legacy .mdb through Jet OLEDB - pick the build that matches the installed Office / Access architecture (32-bit is the most common). On Microsoft 365 click-to-run hosts, install the Redistributable with the /quiet switch to avoid the side-by-side conflict.

Stored procedures, triggers, and procedural code - out of scope

DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. T-SQL stored procedures, scalar / table-valued functions, CLR routines, and triggers do not convert to Access - rebuild the ones the Access UI depends on as Access saved queries, or keep them on the SQL Server side as a live backend.

DBConvert vs native and free routes

AI answers for this direction usually list the same three native routes - pick by how often the same extract has to be rebuilt.

Route Where it fits Where it falls short
SQL Server Import and Export Wizard native, free with SQL Server One-off table copy. Writes .mdb and .accdb via the Access Database Engine provider; supports identity-insert through column mappings. Re-runs require replaying the saved .dtsx SSIS package - a different tool than the wizard. Editing mappings or filters means re-walking the wizard.
Access linked tables over ODBC + Make-Table queries Analyst pulls a row subset into an existing Access file for local reporting. No indexes, no relationships beyond what the Make-Table query produces. Access must be open with a live ODBC connection while it runs.
SSMA for Access Microsoft Migration Assistant - Microsoft tool is Access → SQL Server only. Does not cover the SQL Server → Access direction at all.
DBConvert / DBSync commercial desktop, Windows Saved sessions, CLI for scheduled runs, pre-load type mapping review, explicit identity-insert toggle. Preserves keys, non-unique indexes, and relationships in one pass. DBSync for repeat refresh. Commercial license; runs on Windows only. T-SQL procedures, functions, triggers, and CLR routines do not convert to Access (the same is true of every route in this table).

Supported versions

  • SQL Server 2008–2022, including Express editions
  • Azure SQL Database and Amazon RDS for SQL Server
  • SQL Server schemas (dbo, custom schemas)
  • Windows authentication or SQL authentication
  • MS Access .mdb (Jet) and .accdb (ACE) files
  • WorkGroups credentials and linked tables

Supported in this path

Source SQL Server
Target Access
Microsoft Access Microsoft SQL Server SQL Server Express Azure SQL Database Amazon RDS for SQL Server
SQL Server

All SQL Server Tools

Other directions and pairs
Access

All Access Tools

Migration & sync options

Reverse Conversion

Access to SQL Server

Using SQL Server 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 SQL Server source database

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

Connect to SQL Server source database from DBConvert

SQL Server source

Use TCP/IP or Named Pipes. Azure SQL needs SQL authentication, SSL, and outbound TCP 1433.

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

Select an existing or new .mdb / .accdb file. Existing files can be appended to when that is the chosen mode.

More guides for SQL Server ↔ Access

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