Effortless Upgrade from Firebird 1.5 to Firebird 3: Our Journey and Tools

Navigating a database upgrade from Firebird 1.5 to Firebird 3 can seem daunting, especially with the web filled with tales of woes.

Join us as we unveil how we simplified this task, shedding the common hurdles and introducing a handy tool that turned the ‘painful’ into ‘painless’.

Whether you’re dealing with small databases or behemoths, discover how our journey could ease yours.

Are you used to working with popular databases, such as MySQL, Oracle, SQL Server, Postgres, or MongoDB, but now you’re working on a project using Firebird 1.5 and you’re missing certain aspects of functionality? Does your project not allow you to change the database provider, but you have the capacity to upgrade from Firebird 1.5 to Firebird 4, yet every article you find online suggests that it’s a painful process? We had that same problem; do you want to know how we solved it? 

Firebird 1.5 is very limiting compared to other databases, and certain compared to Firebird 3 or Firebird 4, but it is possible to upgrade a Firebird 1.5 database using the backup and restore options. 

There are some fundamental differences between Firebird differences, in some cases stored procedures might be using functions that have different parameters between versions. We didn’t come across this, but there’s a possibility that you might need to validate your stored procedures following a restore, just to ensure that they compile and work correctly. 

Of course, if you want to backup and restore a Firebird database, you typically need Firebird installed on the system that you’re using to perform the operations. If you want to upgrade the database, you’ll need to perform the backup in Firebird 1.5, uninstall Firebird 1.5, install the new version of Firebird, and then restore the database into that new version. For a one-off shot, that’s all well and good, but if you’re got multiple databases to upgrade it could be a time-consuming problem. Do you backup all databases before changing Firebird versions and performing the upgrade? Do you have dedicated systems for each Firebird version? Do you repeatedly uninstall and install Firebird versions on the local system for each database? 

We had these kinds of problems, so how did we solve them? Well, we wrote ourselves a little internal tool that uses embedded Firebird which loads and unloads the relevant libraries as required. Our tool allows us to backup and restore databases in their same version, Firebird 1.5 to Firebird 1.5, or upgrade each database from Firebird 1.5 to Firebird 3, and you don’t have to install/uninstall Firebird versions from your system. You don’t even need Firebird installed on your system, because everything’s embedded it’s all done for you. 

On smaller databases the upgrade process is quite quick, but if you’re dealing with a database that’s 60GB with triggers all over the place, and a load of indexes, you could be waiting hours for it to backup and restore, but you can just leave it running on a server and come back when it’s finished. The advantage of using backup and restore is that it forces the garbage collection to run, so any deleted records that are hanging around will be removed. We found that the database shrank quite considerably in some cases. 

We did find an interesting problem during the testing of the tool. We packaged the tool as an installer, so it contains everything it needs to perform upgrades, but we found that older servers couldn’t work with the newer libraries for Firebird 3. Well, technically it wasn’t the Firebird files that caused the problem, but rather the MicroSoft libraries. Early versions of MicroSoft Server can’t run MSVCP100.DLL or MSVCR100.DLL due to compatibility issues, so our embedded program couldn’t perform the restore into Firebird 3 on that particular system. 

Perhaps our tool might be of use to you, if you feel it might be, please feel free to get in touch.