DBConvert reads a SQLite file and writes a new Access
.mdb or .accdb. Access files are
capped at 2 GB, so large SQLite sources should be filtered or
split.
Type affinity to Access fields
SQLite stores values flexibly; Access needs declared fields.
Review long text, numeric precision, booleans, date values,
and binary payloads before the target file is created.
SQLite rowid-backed keys need an Access AutoNumber or Number
policy. Confirm next values before users begin inserting rows
into the Access file.
SQLite dates may be stored as text, integers, or real values.
Access Date/Time and Yes/No fields need consistent conversion
rules before reports or forms depend on them.
Supported SQLite views can move as database objects, but
SQLite-only functions, LIMIT, dynamic typing
assumptions, and application SQL need Access-specific review.
Application objects boundary
DBConvert migrates tables, supported views, and foreign keys.
Access forms, reports, macros, modules, VBA, and UI workflows
are created separately if Access becomes the front end.
Type mapping checkpoints
SQLite
Access
Notes
INTEGER
Number / AutoNumber policy
Check rowid assumptions and next values.
REAL, NUMERIC
Number / Decimal / Currency
Preserve precision and scale for reports.
TEXT
Short Text / Long Text
Long values need Access Long Text storage.
Date stored as text/integer/real
Date/Time
Normalize date convention before conversion.
Boolean stored as integer/text
Yes/No
Keep nullable values if the source uses them.
BLOB
OLE Object / binary storage policy
Validate with real payloads, not only row counts.
Application logic - out of scope
DBConvert's migration covers tables with their fields, types, and indexes, and the
relationships between them. Access forms, reports, macros, VBA, and front-end workflows
are not generated from a SQLite application - the front end is built against the new
Access file as a separate workstream.