Access
Firebird

Access to Firebird / Interbase Converter

Move Access .mdb or .accdb data into Firebird or InterBase with type-mapping review, supported query conversion, saved sessions, and optional staged synchronization.

Access → Firebird migration moves tables from a local .mdb or .accdb file into a Firebird .fdb database or Firebird server.

The usual goal is to move a desktop Access data store into a server database while deciding what stays in Access as a front end. Tables and supported queries can move; forms, reports, macros, VBA, and application workflows remain a separate workstream.

What DBConvert does on this path: handles Access → Firebird as a repeatable desktop workflow:

  • Reads Access .mdb and .accdb files through the matching Jet / ACE provider, including WorkGroups when configured.
  • Writes to a Firebird .fdb file or Firebird server target with table and field mapping review.
  • Moves tables, rows, indexes, relationships, and supported Access queries where they can be represented as Firebird objects.
  • Saves sessions for repeat loads; DBSync keeps Access and Firebird aligned during a staged rollout.

What it does not do: DBConvert does not rewrite Access forms, reports, macros, VBA, or front-end workflows into a Firebird application.

Which tool: DBConvert or DBSync?

DBConvert for Access → Firebird

One-time migration or repeatable test loads. Use it when Firebird is becoming the backend and you need Access tables, data, indexes, relationships, and supported queries moved through a desktop wizard.

DBSync for Access ↔ Firebird

Staged cutover or recurring exchange. Use it when the Access file must keep working while Firebird is populated, tested, or gradually becomes the target of record. Review synchronization concepts.

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

How DBConvert handles the Access → Firebird differences

DBConvert handles the database side in the wizard: Access file connection, table selection, type mapping, Firebird target creation, transfer, and validation. Access application design remains separate work.

Access driver and source file

DBConvert reads the source .mdb or .accdb through Jet / ACE. Passwords, WorkGroups, and 32-bit versus 64-bit provider choices should be checked before the first test run.

Firebird target

Write to a Firebird .fdb file or server target. Confirm page size, character set, and target schema policy before loading production-sized data.

Field type mapping

AutoNumber, Yes/No, Currency, Date/Time, Long Text, OLE Object, Attachment, Hyperlink, lookup, and multivalue fields need Firebird-compatible storage decisions.

Generated values and keys

Access AutoNumber columns need a Firebird identity, generator, or sequence policy. After import, confirm next values before Firebird starts accepting application writes.

Query cleanup

Supported Access queries can become target-side views, but queries that call VBA, form controls, Access-only functions, crosstabs, or parameter prompts need manual review.

Application objects boundary

DBConvert migrates tables, supported views, and foreign keys. Access forms, reports, macros, modules, VBA, and UI workflows are not converted into Firebird PSQL or application code.

Type mapping checkpoints

Access Firebird Notes
AutoNumber Identity / generator-backed integer Check next values after import.
Short Text / Long Text VARCHAR / text BLOB Review character set, length, and memo content.
Number / Currency INTEGER, BIGINT, DECIMAL Preserve precision and scale for financial columns.
Yes/No BOOLEAN or small integer policy Keep nullable values if the Access source uses them.
Date/Time TIMESTAMP Check date-only and time-only semantics in reports.
OLE Object / Attachment Binary BLOB policy Validate with real attachments, not just row counts.

Choosing the Access → Firebird route

Most projects are either a backend move for an existing Access app, a full retirement of the Access file, or a staged bridge.

Route Where it fits Where it falls short
DBConvert / DBSync Access file migration to Firebird, type mapping review, supported query conversion, saved sessions, or staged synchronization. Access forms, reports, macros, and VBA still need separate handling.
Access linked tables The Access UI should remain while Firebird becomes the backend for shared tables. Not a full application migration; forms/reports must be tested against linked Firebird tables.
Manual export/import A small number of simple Access tables can be exported and loaded into prebuilt Firebird tables. You own DDL, load order, type cleanup, indexes, keys, retries, and validation.
Application rewrite The Access front end is being replaced by a web, desktop, or service application. This is a software project beyond database conversion.

Supported versions

  • MS Access .mdb (Jet) and .accdb (ACE) files
  • WorkGroups credentials and linked tables
  • Firebird 2.x, 3.x, 4.x and InterBase

Supported in this path

Source Access
Target Firebird
Microsoft Access .mdb Microsoft Access .accdb Firebird 2.x, 3.x, 4.x InterBase
Access

All Access Tools

Other directions and pairs
Firebird

All Firebird Tools

Migration & sync options

Reverse Conversion

Firebird to Access

Using Access to Firebird 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 Firebird destination database

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

Connect to Firebird target database from DBConvert

Firebird target

Write to a Firebird .fdb file or server — Firebird target settings.

More guides for Access ↔ Firebird

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