A directory of data access products for Delphi

Why Not the BDE/DataSnap/DBExpress?

You should first consider the tools in the Delphi / C++B box for your database access needs. That used to be the just BDE, but the BDE is now a legacy technology, replaced by the much better DataSnap architecture (ClientDataSet), DBExpress, and the DBExpress drivers. This solution has many strengths, including:

  • It provides some degree of database independence, although depending on the databases, you may or may not be able to switch without some re-writing. Some databases are supported very well, such as Interbase. Some useds have reported various kinds of difficulties with other databases.

  • It comes in the Delphi box, so you don’t need to buy it separately, keep it up to date, etc.

  • If you need to hire some additional programmers, it will be much easier to find them with DataSnap / DBExpress experience than with experience with the various third-party products.

  • It offers the best third-party tool compatibility - essentially every custom data grid, combobox, date selector, and every other kind of data-aware widget is most thoroughly tested with ClientDataSet/DBExpress. (Most of them also work with the alternatives on this site.)

  • If you are doing multi-tier development, DataSnap is worth a long look. It lets you deploy just a single DLL to client computers instead of the whole BDE. Since you are already using DataSnap inside your client application, moving to a multi-tier DataSnap solution is quite easy.

  • The built in components will be immediately updated and compatible with each new Delphi release, while you may need to wait a while for the other products to be updated.

BDE Weaknesses

The BDE has (had) a number of weakness, which is a big reason so my many BDE Alternatives exist and this Guide is useful:

  • Deployment of the BDE is large and often painful. If a user has another BDE-based app it can conflict with your app. Deployment the BDE is a multi-megabyte install, adding to the size of your software distribution. The rapidly increasing size of hard drives and use of CD-ROM has made this nearly a non-issue, except in software to be downloaded by consumers. Deployment and support costs continue to be high.

  • Its underlying architecture is oriented toward Paradox and dBASE file server based tables - it never quite “feels right” with database servers, in the sense that it seems as though the BDE is trying to pretend that a DB server is really just a big Paradox table.

  • BLOB problems: several of the SQL Links drivers do not work well with BLOB data types.

  • As with any middleware, the BDE is a layer in between your application and the underlying database; such layers always have some kind of performance penalty. The is particulary annoying when your are using the BDE to use another layer of middleware, such as ODBC; in that case, the ODBC layer is necessary, but the BDE layer is “extra”.

  • Also as with any middleware, there will be some underlying features that the BDE does not expose; for example, when using Interbase, the BDE cannot access Interbase array types. The BDE does not yet support Oracle8. (BDE 5, part of the just announced Delphi 4, now supports Oracle8 with all of its new daratypes).

  • Cost: the Enterprise version of Delphi, which includes the BDE SQL Links, costs thousands of dollars. For any particular DBMS, you can find a solution here that will likely be faster, smaller, simpler, easier to develop with, and cost much less than that.

  • Specific Problems: The BDE has specific issues with some databases, which will affect you if you use those databases. For example, its handling of mutliple queries at the same time with MS SQL Server is weak compared with some of the BDE alternative products.

DataSnap / DBExpress

Many of the above downsides have been addressed effectively by DataSnap / DBExpress, but reason still remain to consider third party alternatives:

  • The DBMS you are using may not be well-supported by DBExpress. For example, as I write this, The Borland DBExpress drivers have a significant problem with transaction support in MySQL.

  • You may need zero-DLL deployment, while DBExpress requires driver DLLs.

  • You may benefit from access to special features of your DBMS, which DBExpress does not expose, such as various data types etc. This issue is frequently relevant to Oracle users, for example.


Another tempting and very worthwhile option to consider, including in the Delphi / C++B box, is ADOExpress. ADOExpress is good enough, and general enough, that it is the right default choice for a very wide variety of situations.