A directory of data access products for Delphi

How to Choose a Delphi Data Access Solution

Delphi database application developers have many database systems and data access methods to choose from: the Borland Database Engine, or one of the 20+ BDE alternative products described on this site. How do you choose? The simple answer is:

  • Choose the type of solution based on application requirements;
  • Choose the particular solution based on technical merit.

The longer answer involves looking at a number of issues: are you committed to a specific database format (DBF, for example)? Do you need to connect to a corporate Oracle server for all data storage? What kind of database is appropriate for your application?

Step 1: Choose the kind of database you will use

Database access methods can be broken down in to several categories. In order to discuss the choice of a BDE alternative, it is important to first choose the right kind of database for your application:


With a local database, the data is on the same computer as the program (and the person using it).

Multi-user File Server:

The data is on a file server; all processing occurs on the clients, which essentially treat the server as a shared hard drive on a long wire. The requests transmitted between the user computer and the file server are very low-level: “open file X”, “read 100 bytes”, etc. File-server databases are inherently prone to corruption: if any user computer for any reason cannot complete a database update, the database can be left in an inconsistent state, which will require that all users exit the database application for repairs. Therefore, I recommend file server databases only if:

  1. The application is not vital to minute-by-minute company operations, and
  2. Security is not vital, and
  3. There are less than about 15 users, and
  4. There is a good reason not to choose a client/server solution; for example, allocating anything other than a file server is organizationally impossible.

It is worth noting that in some situations well beyond these limits, file server systems still work well. For example, if users do mostly lookups on indexed fields and very little data updating, and are on a fast local network, file server based databases can occasionally scale to hundreds of users!

Multi-user Client / Server:

The clients (users’ computers) send high level requests to the server: “find all products with a price < $100”. Therefore, more of the processing occurs on the server and less data needs to be transmitted to the clients. The clients never have direct access to the database files and therefore are not able to corrupt them. A Client/Server architecture offer greatly improved resistance to file corruption, and better performance with a large number of users. Therefore, I recommend client/server databases if:

  1. The application is vital to minute-by-minute company operations, OR
  2. Security is important, OR
  3. There are more than about 15 users, OR
  4. Any of items 1-3 might become true in the future.


For widely distributed data access, web-based solutions offer great scalability and easy deployment; unfortunately this site does not cover this increasingly important topic in depth. Suffice it to say that if you are developing a web-based application, you should choose a database and database access software which is well-suited to a multithreaded environment in which many transaction are occurring simultaneously.


One or more “third tier” application servers sit in between the client software and database backend(s). This addresses scalability problems and deployment burdens in traditional Client/Server database system. Borland’s MIDAS is an example of a multi-tier system.

The point here is that first you should choose the database, then choose the BDE alternative to access it. To use an automotive metaphor, choosing truck vs. car is more important than Ford vs. Chevy.

For large, line-of-business applications, my inclination is towards a database server for storage, and middleware (ODBC, ADO, or the BDE) for data access. Middleware is a generalized layer between your app and the underlying database. The benefit of this is that it makes changing database later relatively easy. Data access solutions specific to one database system makes such a change nearly impossible. If you need something that ODBC/ADO/BDE can’t deliver (maximum possible speed, single-EXE deployment, etc., then a native solution is appropriate.

Middleware-based solutions include ADO, ODBC, and the BDE.

Proceed to: Step 2: Choose the database format / server