Replace Borland BDE with FireDAC: A guide to secure Delphi modernization without a Big Bang

In many companies the Borland Database Engine (BDE) remains part of business-critical Delphi applications: accumulated domain logic, UI-proximate data access with TTable/TQuery, sometimes still Paradox/dBase, sometimes early client/server installations. The practical reality is often: the software works, users know the processes, and there is no immediate reason in daily operations to “touch anything”. At the same time the technical substrate changes: operating systems are hardened, deployment is standardized, 64‑bit is expected, and data storage should run on database servers with proper rights and backup concepts.

At this point “replace Borland BDE with a BDE-replacement with native connector” becomes a strategic modernization task. BDE-Ablosung mit nativer Anbindung is, in current Delphi releases, the established data access for modern databases. It delivers consistent behavior, robust drivers, Unicode support, monitoring/tracing and an architecture that can serve both desktop clients and services as well as REST servers. The migration is rarely a pure 1:1 component swap — especially not when the legacy application has “priced in” BDE-specific behavior over years (transaction assumptions, data formats, filters/sorts, cached updates, third‑party reports).

This article focuses on the practical approach: how to replace BDE with FireDAC without endangering domain logic and without forcing a big‑bang relaunch? You will get an actionable model, technical target visions and pointers to typical problem areas in production operations.

Why replacing BDE today is more than routine maintenance

As long as a BDE application functions, a replacement looks like mere “code tidying”. In practice the pressure usually arises from operational and risk concerns.

Deployment, security baselines and “no‑touch” clients

Historically the BDE was designed for local configuration (BDE Administrator, alias definitions, NetDir, shared configuration files). In modern environments manual steps and machine‑wide settings are hard to reconcile with software distribution, hardening and auditability. FireDAC allows far more controllable deployments because connection parameters and driver settings can be managed close to the application.

64‑bit, Windows modernization and new platform targets

Once an application must run in 64‑bit (memory needs, driver/office ecosystem, new hardware, terminal‑server strategies), the BDE effectively becomes a blocker. FireDAC supports 32/64‑bit consistently and is therefore a core component of any Delphi modernization that must not fail on data access. Incidentally, topics like Windows 11 ARM64 and hybrid client/service architectures only become reliably plannable with this foundation.

Database strategy: move from file‑based to server‑based

Many BDE applications still carry legacy from Paradox/dBase times. Those file databases are more fragile in multi‑user operation, harder to secure administratively and poorly suited to current requirements (roles/permissions, encryption, monitoring, high availability). FireDAC is not “the new Paradox driver”, but the modern route to SQL Server, PostgreSQL, MariaDB and Firebird. In practice the BDE replacement is often the trigger to professionalize data storage and operations.

Maintainability and diagnosability in production

An underestimated cost factor is troubleshooting: sporadic locking issues, inconsistent cursor behavior, hard‑to‑trace parameter conversions or network/path problems. FireDAC provides logging, monitoring and clearer type behavior, which give better starting points for reproducible error analysis. For companies operating an application long‑term and extending it selectively, that is an immediate benefit.

BDE vs. FireDAC: differences that matter in migration

On paper components can be mapped. In reality it’s about behavioral changes that can have domain side effects. A brief orientation:

Component mapping (as a starting point)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (in modernizations often preferable: query/view‑based access)
• TStoredProc (BDE) → TFDStoredProc

The most common behavioral differences

• Parameters and data types: FireDAC works more precisely. “It’ll be fine” SQL fails earlier (e.g. dates as strings, implicit conversions, unclear nullability).
• Transactions: Legacy code often contains implicit commit assumptions (closing a dataset, AutoCommit‑like patterns, cached updates). With FireDAC deliberate transaction control pays off because it improves domain consistency.
• Cursors/fetch: FireDAC has different defaults and more tunables. Inefficient patterns (large result sets for UI lists) become visible, but can be optimized deliberately.
• Unicode: In modern Delphi versions Unicode is standard. The FireDAC chain (client library, connection options, DB collation, field types) must be consistent, otherwise character and comparison issues will arise.
• Deployment: Depending on the DB, client libraries are required (e.g. libpq for PostgreSQL). This must be planned early to avoid surprises close to production.

Target architecture for a FireDAC setup: stable, testable, extensible

A BDE replacement should not end in “FireDAC everywhere somehow”. A sustainable target architecture is especially valuable if the application will be further developed or embedded in services/portals.

Minimum goal: unified connection layer

Instead of distributed connections in forms, a central connection layer is recommended:

• Creation and configuration of TFDConnection in one place
• Consistent timeouts, encoding/character set, error handling
• Switching Dev/Test/Prod without manual rework
• Optional: central activation of tracing/monitoring for diagnostics

Recommended: explicit transaction boundaries in domain logic

Many legacy applications spread data changes across UI events. That increases the risk of partial updates and complicates testing. A robust FireDAC approach is: the use case (service/domain logic) starts and ends the transaction, not the UI. Even in a pure VCL desktop application this creates a resilient core that is easier to reuse later as a service or API.

Expandable toward services and REST

If you later add a REST server, operate Windows or Linux services or want to connect a customer portal, you will benefit from a clean data layer. FireDAC is suitable provided connection management, error handling and — depending on server load — pooling are considered in the target vision. This does not have to be implemented in the first step, but the architecture should not block it.

Migration strategy: introduce FireDAC incrementally, decommission BDE in a controlled way

In B2B environments a big bang is rarely realistic: too many domain processes, too much operational responsibility, too little acceptance for long downtimes. A staged BDE replacement is generally the safer path.

Phase 1: inventory and risk map

A useful inventory counts not only components but evaluates behavior and couplings:

• Which database(s) are used: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Where are TTable accesses used, where is SQL used via TQuery, where are stored procedures?
• How are transactions handled today (explicit, implicit, cached updates, mixed patterns)?
• Which reports/exports expect certain dataset properties (sorting, filter, calculated fields)?
• Which third‑party components or in‑house frameworks are BDE‑specific?

From this map it becomes clear whether the replacement only affects access or whether a parallel database rework (e.g. Paradox → SQL Server/PostgreSQL/MariaDB) is sensible or mandatory.

Phase 2: FireDAC foundation (without UI change)

Before migrating screens, FireDAC should be technically sound:

• Central DataModule or service class with TFDConnection
• Configuration model for connection strings (e.g. INI/JSON) and sound secrets management
• Standardized error handling (map DB exceptions to understandable, loggable messages)
• Tracing/monitoring options for pilot operation (activatable, not permanently noisy)

It is important that binding standards emerge from this: naming conventions, parameter rules, logging schema, default settings per database.

Phase 3: pilot module with real domain relevance

A good pilot area is domain‑bounded but actually used. Goal: develop and verify patterns.

• TQuery → TFDQuery (including parameterization and typing)
• Define transaction frames and make them visible in code
• Verify result equality (compare domain‑relevant result sets)
• Measure performance (response times, DB load, network traffic)

At the end of the pilot there should be an internal checklist by which every subsequent module is migrated. That reduces risk and makes effort more predictable.

Phase 4: bulk migration and deployment cleanup

After the pilot modules are converted, migration proceeds module by module. In parallel BDE is removed as an operational dependency:

• Remove installer scripts and documentation for BDE setups
• Eliminate alias definitions, NetDir configuration and special paths
• Align build/release pipeline to new dependencies (client libs, drivers)

This cleanup is essential: as long as BDE parts survive in the deployment, the operational risk remains.

Pitfalls: common causes of domain side effects

Many migrations fail not because of FireDAC but because of implicit assumptions in legacy code. These areas should be prioritized early.

SQL dialects and historically grown SQL

BDE applications often contain SQL that happened to work with a specific driver: implicit joins, inconsistent alias usage, DB‑specific functions, unclear sort orders. In the migration:

• Make SQL explicit (JOIN syntax instead of implicit WHERE joins)
• Check reserved words and identifiers (e.g. DATE, USER, ORDER as column names)
• Unify or encapsulate date/time and string functions

FireDAC offers adaptation options, but the sustainable solution is DB‑compliant, readable SQL.

Data type mapping: Boolean, date/time, memo/blob, NULL

In practice BDE interpreted a lot. FireDAC is more precise — which is good, but requires rules. Typical topics:

• Boolean: BIT/SMALLINT/CHAR(1) — define domain semantics clearly, avoid implicit conversions
• Date/time: DATETIME vs. DATETIME2, milliseconds, sort/compare logic; timezone questions in distributed systems
• Memo/Blob: fetch behavior (OnDemand), encoding, client memory consumption
• NULLability: legacy code that mixes empty strings and NULL leads to subtle logic errors

A lean data type catalog has proven effective: target types per domain‑relevant table/column (DB and Delphi) plus rules for NULL, defaults and formatting.

Transactions: from implicit to deliberately orchestrated

In legacy Delphi projects a common mistake is that the system relied on implicit commits (“if I close the dataset it’s saved”). FireDAC provides explicit APIs (StartTransaction, Commit, Rollback). The modernization benefit appears when transactions are understood as a domain framing:

• Use case starts the transaction
• Multiple updates run within the same connection
• Commit/rollback is centralized with traceable error handling

This reduces inconsistencies and is crucial when the application is later extended with services or interfaces.

Cached updates and conflict handling (concurrency)

Many BDE applications use cached updates as an “offline edit” mechanism. FireDAC can do similar things, but the rules must be explicit:

• Which fields are keys, which are used for concurrency checks?
• How are conflicts resolved (RowVersion/Timestamp, “last write wins”, user decision)?
• What happens on partial failures in batch operations?

In modernizations it is often sensible to move conflict logic closer to the domain logic or into a service layer instead of hiding it exclusively in UI dataset behavior.

TTable/Paradox‑centric applications: FireDAC is not the only issue

If the application strongly relies on file‑based access (TTable against Paradox), then “replace BDE with FireDAC” is only part of the story. FireDAC is primarily aimed at SQL databases. The central decision then is: will data storage be modernized to a server DB?

• Migration to SQL Server, PostgreSQL or MariaDB
• Introduction of a roles/permissions concept and reliable backup/restore processes
• Stable multi‑user operation without file‑locking problems

If an immediate database change is not organizationally possible, a two‑step approach is pragmatic: first stabilize the access layer and reduce UI coupling, then perform the data migration with a clear test and cutover strategy.

Reporting, exports and third‑party components

Reports often depend on details: sort orders, filter precedence, calculated fields, master/detail behavior. For a controlled transition:

• Identify critical reports and treat them as a regression test suite
• Generate deterministic datasets for reports (views/stored procedures or clearly defined queries)
• Reduce UI‑side filter chains that depend on dataset behavior

The goal is reproducible result equality, especially for audit‑relevant evaluations.

Architecture upgrade during the FireDAC migration: pragmatic decoupling

The BDE replacement is a good opportunity to pull data access out of forms and event handlers. This does not mean a full re‑architecture project is required. Moderate measures often have large impact.

Pragmatic target structure (compatible with Layer-3 architecture)

• Connection/Unit‑of‑Work: manages connection and transaction, provides query objects
• Repository/DAO: encapsulates SQL and data access per domain area
• Service/Use Case: orchestrates domain logic, validations and transaction boundaries

This structure is compatible with a later Layer-3 architecture and facilitates follow‑up projects: REST interfaces, background services, multi‑platform clients or integration with portals.

Important effect: fewer global side effects

Many BDE projects work with global data modules and implicit state. FireDAC can work that way too, but modernization is more stable when state is localized: clear lifecycle for connection/transaction, reproducible error paths, fewer side effects from global state.

Performance and stability: configure FireDAC deliberately

FireDAC is powerful, but performance is the result of SQL, indexing, fetch strategy and connection management. In migrations it often appears that BDE masked inefficient patterns because data volumes used to be smaller or the system ran locally.

Fetch strategies and UI lists

• Load only required columns for lists (no SELECT *)
• Server‑side sorting and targeted filters instead of client‑side chains
• For large data sets: paging or incremental loading
• LOB fields (memo/blob) load only when actually needed

FireDAC provides appropriate options; the critical factor is the domain decision about which data a user really needs in each context.

Prepared statements and parameterization

Parameterized queries are not only a security standard (avoid SQL injection) but improve plan reuse on many databases. They also expose type imprecision in legacy code and allow targeted correction. In grown systems this is a quality gain that translates into fewer special cases and better diagnostics.

Connection management: desktop vs. service/REST

In classic desktop clients a long‑living connection per client is often practical. In services or REST servers other patterns apply: short‑lived requests, parallel accesses, connection pooling. If you see the BDE replacement as part of a larger modernization, consider these differences in the target vision so that later extensions do not have to restart at the data access layer.

Test and acceptance strategy: demonstrate result equality

In BDE replacements the main risk is rarely “the application won’t start” but rather subtle domain deviations: sort orders, rounding, NULL handling, transaction boundaries, side effects from triggers/constraints in modern DBs. A viable test strategy includes:

• SQL regression: execute critical queries against defined test data and compare result sets
• Use case tests: check core processes (e.g. posting, releasing, reversing, import/export) against expected outcomes
• Multi‑user/stability tests: locking behavior, deadlocks, timeouts, transaction durations
• Logging/observability: capture DB errors structurally (error codes, context, affected query), not just “error dialog”

Companies benefit doubly: tests secure the migration and create a basis to roll out later changes to the data model or interfaces in a controlled way.

Target databases in FireDAC projects: typical options

FireDAC is intentionally broad, but each database brings its own rules. In modernizations the following targets are common:

SQL Server

Typical in Windows‑dominated IT landscapes. Key points: consistent Unicode types (NVARCHAR), modern time types (DATETIME2), clear identity/sequence strategy, defined isolation levels and proper lock handling.

PostgreSQL

Strong on integrity and features. Migration‑relevant items: identifier case sensitivity, data types (boolean/uuid/jsonb) and dialect differences. FireDAC can connect PostgreSQL productively when client libraries and deployment are well organized.

MariaDB/MySQL

Common when desktop software integrates with web or portal components. Important: utf8mb4 consistently, InnoDB as the engine, a clear transaction and index strategy. FireDAC supports MariaDB/MySQL reliably when parameters and types are clearly defined.

Regardless of the target: a BDE replacement is most stable when database standards are established in parallel (schema versioning, migration scripts, roles/permissions, backup/restore, monitoring).

Practical recommendations for a plannable FireDAC migration

Reduce dependencies before swapping many components

If SQL and dataset logic are embedded in many forms, every change becomes expensive. An intermediate step that consolidates SQL into a few access classes significantly reduces the migration surface. After that, the actual switch to FireDAC is often faster and less risky.

Migrate a transactional core process early

“Simple lists” are convenient as an entry point, but it is lower risk to migrate early a process with real updates and dependencies. If transactions, data types and error paths are sound there, the remainder of the migration becomes more predictable.

Treat deployment as equally important work

Code changes are only half the task. Clarify early:

• Which client libraries/drivers are required per database?
• How are these versioned, signed (if relevant) and rolled out?
• How are connection parameters managed and who is authorized to change them?
• What does the support process look like when DB accesses fail?

Use FireDAC as a modernization anchor — without a restart

The replacement is an opportunity for targeted quality levers: parameterization, transaction boundaries, logging, uniform error messages. This reduces operating costs and makes later extensions (interfaces, services) significantly less risky, without reinventing the application’s domain behavior.

Conclusion: replacing BDE with FireDAC is controllable modernization — if treated as an architectural topic

BDE has supported many Delphi applications for years. Today, however, it is a structural risk: for 64‑bit, for standardized deployment, for modern security requirements and for connection to contemporary databases. FireDAC is the appropriate successor, but not as an “overnight component swap”. The safe route is a staged migration with a clean foundation, a pilot module, binding rules for data types and transactions and tests that demonstrate result equality.

If you want to plan the BDE replacement in a structured way — including inventory analysis, migration path and FireDAC target architecture — a technical alignment of your constraints is the most sensible next step: https://net-base-software-gmbh.de/kontakt/