Access
SQLite

Access to SQLite Converter

Move Access databases to single-file SQLite for embedded use, mobile apps, or local snapshots. Schema conversion, type mapping, and optional two-way sync — works in both directions.

An Access .mdb or .accdb file ties data to the Office Jet or ACE driver and 32 / 64-bit bitness gymnastics on Windows. Migrating it into a SQLite .db file removes both dependencies.

The result is a single-file database any language or platform can open through the SQLite library - iOS, Android, Linux servers, embedded systems, web back-ends, anywhere SQLite runs. The engineering cost is concentrated in type mapping, foreign-key handling on the SQLite side, and deciding what to do with Access application objects (forms, reports, macros, VBA) that have no SQLite equivalent.

What DBConvert does on this path: handles Access-to-SQLite migration as a guided desktop workflow:

  • Reads Access .mdb (Jet, 32-bit) and .accdb (ACE OLE DB, 32-bit or 64-bit) source files, including password-protected files and WorkGroups.
  • Maps Access fields to SQLite affinity types with per-table review, then creates a SQLite .db file with tables, primary keys, foreign keys, and indexes.
  • Saves the migration as a session for repeated runs, with CLI and scheduler support for periodic refreshes.

What it does not do: Access forms, reports, macros, and VBA are part of the Access application, not the database file - SQLite has no equivalent layer. Those stay in Access or are rebuilt in the new application UI (mobile app, web front end, etc.).

Which tool: DBConvert or DBSync?

DBConvert for Access → SQLite

One-time extract. Use it when you need a portable .db file built from an Access source - for embedding in an app, distributing offline, or seeding a mobile / web backend.

DBSync for Access ↔ SQLite

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

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

How DBConvert handles the Access → SQLite differences

DBConvert handles the database-file migration in the wizard: source driver, table selection, field mapping, relationships, and SQLite file output. Access application objects remain a separate rebuild track.

Driver and bitness

DBConvert connects through Jet or ACE OLE DB on Windows. Pick the DBConvert build that matches the installed Office / Access architecture.

AutoNumber keys

Access AutoNumber columns map to SQLite INTEGER PRIMARY KEY AUTOINCREMENT, where SQLite's rowid mechanism takes over key generation.

Field type mapping

DBConvert maps Access fields into SQLite affinities before the file is written. Review text, currency, date/time, OLE, and attachment columns in the mapping table below.

Relationships and names

Access relationships become SQLite foreign keys, and column names with spaces, punctuation, or reserved words are normalized by the policy you choose in the wizard.

Application objects boundary

DBConvert migrates tables, views, and foreign keys. Access forms, reports, macros, and VBA are application objects and are rebuilt separately in the new front end.

Type mapping checkpoints

Access SQLite Notes
Short Text / Long Text (Memo) TEXT Direct mapping; SQLite has no length cap.
Number (Integer / Long Integer) INTEGER Direct.
Number (Single / Double / Decimal) REAL Or NUMERIC per column policy.
AutoNumber INTEGER PRIMARY KEY AUTOINCREMENT SQLite rowid takes over key generation.
Yes/No INTEGER 0 = No, 1 = Yes.
Currency NUMERIC Or INTEGER cents for exact arithmetic.
Date/Time TEXT (ISO-8601) SQLite has no native datetime; use YYYY-MM-DD HH:MM:SS.
OLE Object / Attachment BLOB Or external file path if large.
Hyperlink TEXT Stores the URL string only.
Lookup field underlying value type Lookup display is an Access UI concept; not stored.

DBConvert vs other Access → SQLite routes

Free routes cover narrow slices: a Linux CLI extract, a GUI ODBC import, a CSV dump. They stop at the boundary where Access field types, AutoNumber rewiring, queries, and relationships need a SQLite answer - which is most of the actual migration project.

Route Where it fits Where it falls short
mdbtools + sqlite3 open-source CLI, Linux / macOS Linux or macOS workflow on .mdb files - mdb-schema exports SQLite DDL, mdb-export dumps tables to CSV, sqlite3 .import loads them. Strong for .mdb (Jet); .accdb support is uneven. No AutoNumber rewiring, no relationship preservation, no query translation, no type-mapping review.
DB Browser for SQLite + ODBC free GUI, Windows Inspect-and-load workflow on Windows - install the Access ODBC and SQLite ODBC drivers, then use DB Browser for SQLite's import-from-database feature. Per-table workflow with fragile ODBC driver setup; no automatic foreign-key preservation, no query translation, no saved repeatable session.
CSV export + sqlite3 .import free, manual Tiny Access databases with simple types and no relationships - export each table to CSV from Access, hand-write the SQLite DDL, load with sqlite3 .import. You write every DDL conversion (AutoNumber, Memo, Yes/No, Date/Time) and every relationship by hand. OLE Object and Attachment columns can't pass through CSV intact. No validation step.
DBConvert / DBSync commercial desktop, Windows Desktop wizard for Access → SQLite with per-table type-mapping review, AutoNumber → AUTOINCREMENT rewiring, query-to-view translation, foreign-key preservation, saved sessions, scheduler, and CLI. Reads .mdb (Jet) and .accdb (ACE), writes a self-contained SQLite .db file. DBSync keeps both sides aligned for repeat refreshes. Commercial license; desktop tool (Windows). Forms, reports, macros, and VBA do not convert - those are application objects either way.

The free routes do the data copy, not the migration. An Access-to-SQLite project spends most of its time on AutoNumber rewiring, type mapping (Memo / Yes/No / Currency / Date-Time / OLE Object), relationship preservation, and query translation. DBConvert puts each of those decisions in a reviewable wizard, saves the session so test loads are rerunnable, and adds DBSync when the Access source must keep running during the rollout. That is what the commercial license buys - not "data copy", which the free routes can already do for tiny schemas.

Supported versions

  • MS Access .mdb (Jet) and .accdb (ACE) files
  • WorkGroups credentials and linked tables
  • SQLite 3.0 and later

Supported in this path

Source Access
Target SQLite
Microsoft Access (.mdb / Jet) Microsoft Access (.accdb / ACE) SQLite
Access

All Access Tools

Other directions and pairs
SQLite

All SQLite Tools

Migration & sync options

Reverse Conversion

SQLite to Access

Using Access to SQLite 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 Access source database

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

Connect to Access source database from DBConvert

Access source

Select the source .mdb or .accdb file. If it uses Access WorkGroups, enable WorkGroups and enter those credentials on the source step.

2

Connect to SQLite destination database

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

Connect to SQLite target database from DBConvert

SQLite target

Write a self-contained SQLite .db file at the path you pick in the wizard.

More guides for Access ↔ SQLite

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