DECISION GUIDE

BDE replacement for Delphi applications:
what replaces it, where the data goes, and what order to do it in.

BY THOMAS JAEGER · PUBLISHED SEP 5, 2026

The Borland Database Engine still sits under many Delphi applications from the Delphi 2 to 7 era, deprecated for longer than most of them have been in service: 32-bit only, never Unicode, and harder to install with each Windows release. This guide covers what replaces it, where the data goes, and in what order.

The short answer. FireDAC when the application is moving to a current Delphi anyway; a third-party library such as UniDAC when the compiler has to stay put. Move Paradox and dBASE tables into a database server in the same change. Data layer first, compiler second; a VM with the old BDE is a dated bridge, not a plan.

What the BDE is, and why it is a liability.

The Borland Database Engine is the data access layer that shipped with Delphi 1 (16-bit) through 7 (32-bit) and stayed, marked deprecated, until Embarcadero removed it from the RAD Studio installer with XE7 in 2014. It drives Paradox, dBASE, FoxPro and text tables natively through its own Local SQL dialect; its SQL Links drivers for server databases were deprecated when dbExpress arrived.

Four facts make it a liability. It is 32-bit only, so a Win64 build is impossible while it is present. It will never support Unicode; Embarcadero's documentation says so. Paradox and dBASE tables on a network share depend on lock files, PDOXUSRS.NET and the .LCK files, that every client must be able to create, write and delete. And its configuration and shared-memory settings land in locations Windows 10 and 11 protect, so a clean install often needs manual work in BDE Administrator first.

Embarcadero still offers it as a separate download for registered users, and it still loads as a 32-bit component on 64-bit Windows. That is a courtesy, not support. Nothing in it will be fixed.

Symptoms you will see.

None of these mean the application is about to fail. Together they mean the data layer now constrains everything else.

Will not open on a new PC
Errors $2501, $210D or $2108 on a fresh Windows 10 or 11 install; the SHAREDMEMSIZE and SHAREDMEMLOCATION settings have to be adjusted in BDE Administrator on each machine.
"Directory is controlled by other .NET file"
Different NET DIR paths or drive letters between clients, and the Paradox tables refuse the second user; it recurs with every replaced workstation.
Index corruption after a network drop
An interrupted write leaves a .PX or .MDX index out of step with its table. Rebuilding the index does not recover rows lost in the interrupted write.
Slow over the network, fast locally
Paradox and dBASE are file-share databases, so every query pulls table and index pages across the wire. There is no server-side fix.
No 64-bit build, ever
The process stays 32-bit, with its address-space ceiling and no 64-bit-only drivers or DLLs. Any Win64 plan starts by removing the BDE.
Accented characters wrong in exports
A table written under an OEM code page reads correctly in the old application and garbles as ANSI or UTF-8 elsewhere.

Replacement options.

FireDAC is the first-class answer. It ships with every current Delphi edition, builds for Win64, and is close enough to the BDE that the product samples include a reFind rules file, FireDAC_Migrate_BDE.txt, for the mechanical rename across .pas and .dfm files. It does not translate Local SQL, and TFDTable emulates the navigational API over a SQL server, so SetRange and FindKey code needs a performance review, not a rename. Check your edition: Professional ships local and embedded drivers only; client/server needs Enterprise or above.

dbExpress and dbGo (ADO) also ship with Delphi and build for Win64. dbExpress datasets are unidirectional, so editable grids need a TClientDataSet layer; dbGo is Windows-only and rides on the installed OLE DB provider, for SQL Server now MSOLEDBSQL. Both are reasonable where already in use.

Third-party libraries such as Devart's UniDAC support compilers back to Delphi 6, so the data layer can move before the compiler does, and their direct-mode drivers need no client library per PC, at the cost of a per-developer license and one more dependency.

The BDE in a VM on an older Windows is a stopgap: it unblocks a PC roll-out, changes nothing about locking, 32-bit or Unicode, and needs an end date.

Migrating the data.

Replacing the components without moving the data leaves Paradox and dBASE files behind a new library with the same file-share locking underneath. The destination is a database server: SQL Server or PostgreSQL where the organization already runs one, Firebird or InterBase where a small server fits, SQLite where the application is single-user.

Paradox and dBASE tables carry a language driver that decides their code page, and DOS-era tables are often OEM-encoded, so a naive byte copy garbles accented characters. dBASE two-digit years, Paradox timestamp precision and the absence of any UTC offset in either format each need an explicit rule. Paradox validity checks and referential integrity live in .VAL files, enforced by the BDE, so the target schema must carry them as constraints or they are gone. Blank fields become a NULL-or-empty decision; autoincrement fields become identity or sequence columns whose high-water mark must survive.

History is preserved, not sampled: every row moves, counts and per-column checksums are reconciled between source and target, and the original files stay read-only as an archive until the parallel run ends.

Sequencing: data layer first, compiler second.

The order matters because the two changes fail differently. A compiler jump from Delphi 7 to Delphi 13 surfaces Unicode string breakage and pointer-size assumptions across the whole codebase at once, and FireDAC does not compile on the old compiler. Doing the data layer first, on the compiler the application already builds with, isolates one class of failure: a wrong report afterwards is a data-layer fault, not a string conversion.

For a small application that means UniDAC or another library with Delphi 7 support, a new database, and a tested release before the compiler moves. For one upgrading anyway and small enough to freeze, both changes in one release on FireDAC is defensible.

For a large application, neither step is safe as a single cutover. A strangler-fig sequence puts a data module or data service in front of the tables, moves one screen or report at a time onto the new database, and keeps both paths in step until the last TTable is gone; the reasons to prefer it are the reasons in the rewrite vs strangler fig guide.

What the assessment inventories.

A BDE replacement is quoted from an inventory, not a guess. That inventory is the first block of the Legacy Software Assessment, a fixed-scope, read-only review, and for a BDE application it records the following.

BDE aliases and driver settings
Every alias in the BDE configuration, its driver (Paradox, dBASE, ODBC or SQL Links), its NET DIR, and which machines carry a different copy.
Data-access component counts
TDatabase, TSession, TTable, TQuery, TStoredProc, TUpdateSQL and TBatchMove counts across all forms and data modules, with CachedUpdates, RequestLive and navigational calls flagged.
SQL embedded in code
Query text assembled at run time, Local SQL with no target equivalent, and parameters built by string concatenation: a porting task and a security finding.
Third-party components bound to BDE datasets
Grids, report engines and export components that expect a BDE dataset, with source and license status.
Tables, indexes and integrity rules
Table families on disk, language drivers, secondary indexes, .VAL rules, and the row counts the reconciliation will be measured against.
The rest of the 32-bit footprint
Everything else that pins the process to 32-bit, so the Win64 question is answered once.

Five ways off the BDE, side by side.

Option64-bitEffortLicensingFits when
FireDACYesModerate; reFind renames, Local SQL and TFDTable need reviewIncluded with Delphi; server drivers by editionThe compiler is moving to a current Delphi anyway
dbExpressYesHigher; unidirectional datasets need a TClientDataSet layerIncluded since Delphi 6The application already uses dbExpress elsewhere
dbGo (ADO)Yes, with a 64-bit OLE DB provider per PCModerate; Windows-onlyIncluded with Delphi; providers from MicrosoftSQL Server or Access already in place
UniDAC or other third-partyYesModerate; direct mode needs no client librariesCommercial, per developer; source at the higher tierThe compiler stays on Delphi 6 to 2010 for now
BDE in a VMNo; the process stays 32-bitLow to set up, permanent to operateNo new BDE license; the VM's Windows needs oneBuying months; never the destination

Common questions

Does the BDE run on Windows 11?

It can, as a 32-bit component under WOW64; Embarcadero still offers the installer as a separate download for registered users. It is unsupported, its defaults conflict with Windows folder permissions, and a working install should be treated as fragile.

Is there a 64-bit version of the BDE?

No. The BDE was never ported to 64-bit, and Embarcadero has stated it will not be enhanced, Unicode included. A Win64 build is impossible while any unit references the BDE; removing it is the first step of a 64-bit migration.

Is FireDAC a drop-in replacement for the BDE?

Closer than any other option: Embarcadero's reFind rules file renames components and properties across .pas and .dfm files. What remains manual is Local SQL the target rejects, TFDTable performance where code leaned on navigational calls, and third-party components that expect a BDE dataset.

Can we keep our Paradox tables and only change the components?

Technically, through an ODBC driver that matches the application's bitness, but you keep the file-share locking, index corruption and network performance that made the BDE a problem. Moving the data to a server is most of the value.

Do we have to upgrade Delphi to get rid of the BDE?

Not first. Libraries such as UniDAC support compilers back to Delphi 6, so the data layer can move on the compiler the application builds with today; FireDAC needs a current Delphi. Data layer first keeps the two classes of failure apart.

How long does a BDE replacement take, and what does it cost?

Inside the bands on the Delphi modernization page: 4 weeks to 8 months and $10,000–$200,000, with a data-layer-only change at the low end. The figure is fixed after the Legacy Software Assessment, whose fee is quoted after the free 1-hour consultation and creditable toward a subsequent modernization project.

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.