Switching From UniDAC to FireDAC

Since upgrading my Delphi subscription from Professional to Enterprise, I've been slowly replacing third-party database components with FireDAC since the Enterprise edition comes with many more databases supported. One of the ones I've used a lot is Devart's UniDAC. UniDAC is a great database component suite. I've used them for many years, they have an excellent support forum, and frequent updates. I just don't want to pay for duplicate functionality--well, mostly duplicate; there are some advantages to using UniDAC but they're not deal-breakers for me.

One of those "not a deal-breaker" advantages is direct database access. Many database vendors require some sort of client-access library or application to be installed in order to access their database. I write a lot of custom applications for Retail Pro 9 which uses an Oracle database on the back end. Each installation of these programs is either on the same server as the Oracle database or on a computer that already connects to the Oracle database. Therefore, I always have the Oracle client already installed. This is key for switching from UniDAC (which offers direct Oracle access) to FireDAC (which requires an Oracle access client installed).

With very little effort, I was able to change the UniDAC components on my data modules to FireDAC components by viewing the data modules as text, doing a textual find-and-replace from TUniQuery to TFDQuery, switching back to form view, saving, then answering Yes to the multiple prompts to correct the corresponding components in the code. This also automatically added the correct FireDAC units I needed and I removed the UniDAC ones I no longer needed--namely, Uni. The connection component was almost as simple and in a shared data module used by all the applications so it didn't take very long.

The only other thing I found I had to do (discovered at runtime) was change several of the fields defined at design-time from the ones UniDAC used to the ones preferred by FireDAC. This simply involved removing the defined fields, activating the new FireDAC query component at design-time, and letting FireDAC add all the fields back in through the Fields Editor. Some (but not all) TStringField entries were replaced with TWideStringField ones; all TLargeIntField, TFloatField, and TSmallIntField were replaced with TBCDField or TFMTBcdField with different Precision and Size values.

Building the installer required another change. These particular applications have to be built with run-time packages so there are several BPLs that must be deployed along with the executable. I'm using Delphi 10.4 Sydney, so instead of Devart's minimum three files for Oracle access, dac270.bpl, unidac270.bpl and oraprovider270.bpl, I need to deploy four FireDAC package files:

• FireDAC270.bpl
• FireDACCommon270.bpl
• FireDACCommonDriver270.bpl
• FireDACOracleDriver270.bpl

These programs have simple database needs, use no stored procedures or special Oracle functions, and do not perform any schema change operations. In fact, all database queries are read-only because of the embedded license used by Retail Pro, so this conversion was relatively straight-forward. If it had been much more complex or if direct database access was really important, the price to renew the second set of database components would've been well worth it.