Working with BDE databases is usually a legacy data job, not a greenfield architecture choice. If you have Paradox, dBASE, or old Borland-era tables still running a business process, the sensible approach is to extract the data safely, validate it, and move it into a modern workflow. Do not start by rewriting the old application. That is how small imports become archaeological digs with meeting invites.
Our ETL products support BDE so you can read legacy Paradox and dBASE-style data, inspect tables, export records, and include old data sources in repeatable import or reporting workflows.
BDE still appears in real business systems
The Borland Database Engine, usually shortened to BDE, was widely used by applications built with Delphi, C++Builder, Paradox, and related tools. Many of those applications are old. Some are still business-critical. Legacy systems have a habit of retiring later than the people who wrote them.
In practice, BDE work usually means one of three things: reading old local tables, migrating data away from a legacy application, or keeping a report alive while the replacement system is still being discussed. The replacement system, naturally, has been "nearly ready" since 2017.
Use BDE support to extract data, not to modernise BDE
BDE is no longer the right foundation for new database work. Treat it as a source that must be handled carefully. The goal is to get the useful data out, check it, and load it into a system that is easier to support.
Good BDE use cases
- Read Paradox and dBASE tables from old applications.
- Export legacy records to CSV, Excel, SQL Server, or another database.
- Validate old data before migration.
- Automate scheduled extracts from a system that still has to run.
Bad BDE use cases
- Building new applications around BDE.
- Using BDE as a long-term reporting platform.
- Manually copying files every week.
- Assuming every old table has clean keys and sensible field names.
That last point matters. If the database was built before 2000, assume nothing. Field names may be cryptic, data types imaginative, and documentation mythical. It is not broken. It is vintage.
Recommended BDE settings reduce avoidable failures
BDE configuration is handled through BDE Administrator, often called BDEADMIN.EXE. The exact settings depend on the application, table type, network path, and permissions. Start by matching the environment the legacy application already uses, then test with a small table before running a full export.
Before scheduling anything, check file access, table locks, code pages, memo fields, and network paths. Old database systems can be very calm until two processes touch the same file. Then they become less calm. So do support teams.
Read the old data before you design the migration
The safest first step is inspection. Open the tables, check row counts, review key fields, and compare a few records against the old application. If the source contains lookup tables, memo fields, or denormalised values, document them before building the workflow. For context on older table formats, Microsoft's documentation still covers Jet and file-based database driver considerations.
- Identify the BDE alias or file path used by the old application.
- Check whether the source uses Paradox, dBASE, or another BDE-supported format.
- Confirm read permissions and whether the application locks tables during business hours.
- Export a small sample and compare it with the legacy screen.
- Build the ETL workflow only after the sample matches.
This is dull work. It is also the work that prevents the 2:00 a.m. surprise where a report is missing half the records because one lookup table lived in a different folder.
Choose the right tool for the job
Use Active Table Editor when people need controlled access to database records through a simple interface. Use Advanced ETL Processor Enterprise when the BDE data needs extraction, validation, transformation, scheduling, logging, and loading into another system.
If the job is a focused import or export, Visual Importer ETL Enterprise may be enough. If the workflow involves transformations, multiple steps, notifications, or error handling, use Advanced ETL Processor. The tool should fit the work, not the other way round.
Do not use BDE for industrial databases if a direct driver exists
BDE can connect to some server databases through additional drivers, but that is usually the wrong route now. If you need Oracle, SQL Server, PostgreSQL, MySQL, or Firebird, use direct database connections instead. Fewer layers means fewer mysteries.
Embarcadero's own documentation describes BDE as a legacy technology, and that is the right way to treat it. Keep it working where you must. Avoid expanding it where you can. Your future self will thank you, probably in a slightly tired voice.
Working with BDE databases FAQ
What is a BDE database?
BDE stands for Borland Database Engine. It is a legacy database access layer used by older Borland and Delphi-era applications, often with Paradox or dBASE tables.
Can Advanced ETL Processor read BDE data?
Yes. Advanced ETL Processor can work with BDE sources so legacy data can be extracted, transformed, validated, and loaded into modern targets.
Should I build a new system on BDE?
No. Use BDE support for legacy access, migration, reporting, and controlled maintenance. For new systems, use a supported database platform with current drivers.
What should I check before extracting BDE data?
Check aliases, file paths, permissions, table locks, memo fields, code pages, and whether the old application must be closed before reading the files.
Can BDE data be migrated to SQL Server or another database?
Yes. Read the BDE source, validate the rows, map the fields, and load the result into SQL Server or another supported database. Test with a sample before moving the full dataset.
If your BDE data is still doing useful work, we can help you move it without pretending the 1990s are coming back. Some fashions should stay retired.