How DBConvert handles the Access → SQL Server differences
Access is both a database file and an application platform; SQL
Server is only the backend. DBConvert moves the database side
(tables, fields, indexes, foreign keys, supported queries) with
sensible defaults that you can review or override per table;
Access application objects (forms, reports, macros, VBA) stay
in Access or are rebuilt outside the migration. See the
Access front-end / SQL Server backend guide
for the application split.
-
Access-specific field types.
Maps AutoNumber to IDENTITY, Yes/No to
bit, Memo / Long Text to nvarchar(max),
Hyperlink to nvarchar(max), Currency to
money, and OLE Object / Attachment to
varbinary(max). Lookup fields keep their
underlying value type; the lookup display is an Access UI
concept and lives in the front end.
-
Access queries → SQL Server views.
Translates supported Access SELECT and
UNION queries into SQL Server views during the
migration. Queries that call VBA functions, form controls,
Access-only functions, or local tables are not translated
— rebuild those in SQL Server views, stored procedures,
or in the new application layer.
-
Linked-table-ready output.
Creates target tables with primary keys preserved from
Access — required for an Access front end to detect
changes through ODBC linked tables. Adding a
rowversion column on heavily-edited tables is a
wizard option that makes Access linked-table updates
conflict-safe.
-
Security and workgroups.
Reads .mdb files that use Access WorkGroups
when those credentials are supplied at the source step;
user-level permissions do not map automatically into SQL
Server logins, roles, or application security —
redesign the security model on the SQL Server side as part
of the cutover.
-
Forms, reports, macros, and VBA — outside DBConvert's scope.
These are part of the Access application, not the database.
DBConvert's migration covers tables (with their fields,
types, defaults, and indexes), views, and foreign keys.
Forms and reports continue to work as a front end against
linked SQL Server tables, or are rebuilt in a web /
.NET / BI front end as a separate workstream.
