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.

DBConvert reads Access .mdb (Jet, 32-bit) and .accdb (ACE OLE DB, 32-bit or 64-bit) files, including password-protected files and WorkGroups, and creates a SQLite .db file with tables, primary keys, foreign keys, and indexes, mapping Access fields to SQLite affinity types with per-table review. 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.


  • DBConvert saves the migration as a session for repeated runs, with CLI and scheduler support for periodic refreshes.

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.

Forms, reports, macros, VBA - out of scope

These are part of the Access application, not the database file, and SQLite has no equivalent layer. DBConvert's migration covers tables with their fields, types, and indexes, plus primary and foreign keys. Forms, reports, macros, and VBA stay in Access or are rebuilt in the new application UI - a mobile app, a web front end, or a desktop client - as a separate workstream.

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 and services

Access

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

SQLite

  • SQLite 3.0 and later

How to migrate Access to SQLite

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

Select the Access file. DBConvert reads its tables and prepares them for mapping.

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

Choose where the SQLite file goes. DBConvert creates it, or writes into the one you point at.

Connect to SQLite target database from DBConvert

SQLite target

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

Steps 3-6: the same for every database pair

Source and target are connected - steps 1 and 2 above. What follows is identical whichever two databases you picked, so it lives in one place. Each step below opens at its own section.

Open the full guide

All four steps in one page, plus software features, command-line mode, scheduler, and system requirements.

See all features