Last week I blogged about migrating applications still based on the BDE components to FireDAC (which is also a great reason for moving to XE5) with the help of the reFind tool. In this related post I want to focus on the database side. If your database is a relational database, you might want to keep the current database engine, provided FireDAC supports it (which is very likely if the BDE supported it).

If your application uses local or network-based tables (like Paradox or dBase, the two local formats supported by the BDE), than this blog post is for you. Before we focus on how you can migrate your databases, let’s consider if you should migrate them.

If I have a Paradox or dBase database, do I need to migrate?

If you want to move away from the BDE components and the from the BDE engine, you can still consider using your existing Paradox files with FireDAC. In fact, FireDAC does support local desktop files.

Specifically FireDAC can be configured:

  • To use Paradox tables via ODBC. This is explained in details by Cary Jensen in the white paper for the October 2013 webinar he did for Embarcadero and available at forms.embarcadero.com/RADinAction-FireDACDataConnectivityWebinar10-30 (notice that this 70-pages paper is absolutely a must read for anyone who wants to get started with FireDAC )
  • To use dBase through ODBC (in a similar way)
  • To support dBase with various types of indexes via Advantage Database (which includes a free local engine and which is directly supported by FireDAC with a specific driver)

The question still applies, though. Is it worth keeping the data in these “ancient” formats? Given these format are really very old and not much supported, I’d generally suggest migrating to a newer engine. If you want to use Advantage Database (and keep an ISAM structure), migrate to their newer ADS format. In general, pick one of the popular relational databases, and move to one of them. The only scenario in which keeping an old database format would make sense is if there are other legacy applications accessing the same files or producing them, and you don’t want to or cannot migrate these legacy programs. (Again, Cary's white paper has some interesting further considerations on why migrating and why not.)

If I move to a relational database, should I move all of my tables to queries?

While this might be a good idea over the long term, along with a good re-organization of your database tables to better take advantage of the capabilities of a relation database, it is not required per se.

FireDAC has good capabilities to let you use the tables in InterBase (or any other local database), as if there were accessed directly. Truly, the ISAM and relational models are different you might experience performance differences, at times requiring you to rethink the user interface (like avoid letting the users browse tables with hundreds of thousands of rows.

While this could probably be debated at length, both moving to queries (with proper filtering) and keeping tables are possible scenarios. The FDTable component has a special “aggressive fetching” mode (called LiveWindowParanoic) to help in navigating large tables, that is the most optimized scenario for large local tables.

More information about browsing tables in FireDAC can be found in the documentation at docwiki.embarcadero.com/RADStudio/XE5/en/Browsing_Tables_(FireDAC) .

Migrating Paradox Databases to InterBase

If you want to migrate your Paradox (or dBase) databases to InterBase you can take advantage of one of the many freely available migration tools. A tool I can certainly recommend is Clever Component’s InterBase DataPump, available as freeware (and documented) at clevercomponents.com/products/datapump/.

Even if this tool is not particularly new, it does a great job in converting Paradox tables to InterBase. The tool is free, but you can consider buying the source code or some consulting from the publisher.

A very nice step-by-step tour of the conversion InterBase DataPump can make is available at clevercomponents.com/products/datapump/dp-tour.asp.

Before I close off this section, let me add while you might want to pick InterBase over other databases. First is is lightweight, which is great for local database, while not cutting on relational features (as other light engines do). Second, you can move these local databases to mobile platforms, along with the matching Delphi and FireDAC code. Third, InterBase supports encryption, which is more and more relevant these days.

An Aside: BDE and Windows 7 or 8

Finally, let me explain you another reason why you should not keep around applications based on the BDE. As you know, Microsoft is going to stop supporting Windows XP in a few months (if this really happens or they'll extend the deadline would be worth a discussion, but this is a separate topic) and this is going to push more businesses to move off Windows XP (if they still haven't done so) to either Windows 7 or Windows 8. And move many systems from 32 bit versions of Windows to 64 bit ones along side.

Now the issue is that while you can generally run most of the legacy Delphi applications on new versions of Windows, installing and configuring the BDE is far from simple. On enteprrise system with strict rules, this might even become impossible. And 64-bit systems don't terribly like the BDE. 

I'm not saying you cannot wrestle with Windows 8 to make it run your legacy BDE applications, but I'm questioning if it is worth fighting this battle, over converting your applications to newer and more reliable technologies.

Summing Up: Buy XE5 Now!

To sum things up, what is the best next step to migrate your legacy BDE applications? It is to buy Delphi XE5, if you haven't already done so, while the current offers last! See www.embarcadero.com/radoffer for more details.