A directory of data access products for Delphi

Step 3: Choose the product to access that database

Having chosen the database file format or database server for your application, finally choose a product (or a few products) to evaluate. When comparing the product, here are some features and topics to consider:

File formats / database servers supported

Obviously you need to choose a product that supports your chosen file format or database server; moreover, you should choose a product that is primarily targeted at the files/servers you are using. Some of the products listed here support many, many formats, but specialize in a few. If you want the best performance, usability, support, use the product the way the vendor has in mind.


The more computers the application must be deployed to, the more important easy deployment is. This can vary widely between products: Some compile completely in to your EXE; some requires DLLs. The client/server solutions require drivers for the database server they are access. Middleware-based solutions (ODBC, ADO, BDE) will require that the appropriate middleware be installed.

For comparison’s sake, the BDE require 2-3 megabytes of DLLs, etc.

Data-aware controls

If you are developing a GUI application, data-aware control support is vital to rapid development. There are certainly situations where data-aware controls are not appropriate, but it is wise to have them available for those times when they are appropriate.

There are three levels of support:

  • None.

  • Proprietary: the product has its own data-aware controls. This is better than nothing, but, in my opinion, not by much. You will have to use only the vendor’s controls, not the controls that come with Delphi, or the hundreds of third-party controls available. Proprietary controls also make it extremely difficult to switch to different data access software later.

  • Standard: most of the products support standard Delphi data-aware controls, using one of two mechanisms explained below:

BDE Replacement Mechanism

In D1/D2, it was necessary to extensively reverse engineer the VCL/BDE interface in order to use standard data-aware controls, because the controls were tied to the VCL’s BDE using classes where none of the methods were “virtual”, and therefore could not be replaced. BDE emulation works, and permits a very BDE-like experience, but it is definitely a kludge, albeit one that some vendors engineered very well.

In Delphi 3, Borland “saw the light” and redesigned the VCL to use a virtualized TDataSet, which makes it possible to create components that can connect to standard data-aware controls as easily as TTable and TQuery do. This method is far preferable to the old BDE-emulation method, and nearly all vendors have switched to it. The new method make installation of BDE alternative much easier, redistribution of your product much easier, etc.

Further Delphi releases have refined the TDataSet concept even more, so that BDE alternatives products based on TDataSets work more smoothly than ever.

Custom Controls:

If you use various custom controls (InfoPower, Orpheus, etc.), you should verify that the product you are considering is compatible with the products you are already using.

For a while, some third-party controls explicitly expect a BDE TTable/TQuery, and simply did not work with any BDE alternative. Some vendors (for example, Woll2Woll) are actively working with BDE alternative vendors to produce special TDataSets that let allow them to work with the controls (InfoPower).

At this point, nearly all custom controls work with a wide variety of BDE alternative products.

Report Printing:

The same advice applies to report generation software (Ace, Report Printer, QuickReports, ReportBuilder, FastReports, etc.)… make sure that you can use your report software with the BDE alternative product you are considering.

Full access to the feature set of the database server?

Some BDE alternatives will provide more access to the underlying database’s feature set than others. For example, database-server-specific products like Interbase Objects and Direct Oracle Access can use the underlying database APIs to make features available that cannot be used via a middleware solution.

Most of the time, this distinction is not important; the middleware-based software support everything that you actually need, and give the advantage of greater database portability. However, if you need a specific feature of a particular database server, you may need to choose a “native” product to get it.

A major issue with with “native” products is that they lock you in to the database they are native to; if you switch databases, you will probably have to switch data access software, which usually means a substantial rewrite of your application.


How trouble-free is it? Are workarounds needed for common actions? Pay attention to support newsgroups and mailing lists to learn this kind if information. (This information will be added to the BDE Alternatives Guide over time, as well.)

Support Policies / Bug Fixes

What kind of support is available? If the vendor is located in a different part of the world, calling may be very difficult; therefore try to get a feel for how quickly and effectively they answer email or support newsgroup queries. All software has bugs, but some software gets fixed much more quickly than others.

Query language support

Many of the file-server-based solutions have no support for any kind of query language; you may find that certain reports which could be generated easily in an SQL-based environment will require significant coding to gather the results “manually” in code. For developers with significant SQL experience, this can be a big step backward.

Important Note…

On the list of products, you can filter by what DBMS or file format you are using.