Distributed applications with Firebird

Source: Firebird Conference 2009 in Munich; Holger Klemt.

When incorporating the Firebird database into your application and distributing it to your customers, there are a number of factors to be taken into consideration, which will minimize installation, update and runtime problems.

Installation

The Firebird ZIP file always includes both the Superserver and Classic server.

Use these files rather than the setup.exe for distribution, integrating them into your installer simply by adding a single line of batch code. This has the advantage that you can directly control the Firebird server from your application and make it run without any entry in the registry or anywhere else. For example, when install_super.bat is called using the parameter fbc2009, it automatically raises a service:

the Firebird Guardian, with the name, fbc2009. This prevents conflicts with any other Firebird installations that may be running on the same machine.

Multi-instance Firebird installation and updates

You can preconfigure the main config files. In the firebird.conf file, for example, you can change the connection string from the standard port to a port of choice, to prevent potential conflicts with any existing Firebird servers running on the same machine, and ensuring that your application connects to the database version that you have installed. You can define the root directory, cache settings and so on. You can change the SYSDBA masterkey combination in the security2.fdb. And you can also use a predefined alias.conf file or simply add an entry at runtime during the installation.

And once the database has been registered in IBExpert, you can see the specified path as you have defined it:

If you need to uninstall the Firebird server at any time, simply use uninstall fbc2009.

Another tip is to store the client library file, the fbclient.dll or the gds32.dll, in the application path rather than in the default search path, System32, as another installation could overwrite your file, or you may inadvertently overwrite a client library used by another application. As Windows always searches in the local directory first, you will not need to worry any further. The client library path can be defined in your installer. Make sure that you remove any Firebird files that neither the customer nor Firebird does not need, such as GFIX.

If you are working on a computer that has no administrator rights, install Firebird as an application using the -a parameter:

 C:\Program Files\Firebird\bin>fbserver -a

This is a good option if the installation is on a machine where only one user will be using the database. In a workgroup situation it may be better to use the Service version, as this starts the server automatically, even if no one is logged on.

So, you can install different versions or different implementation of the same version on your machine and let them run at the same tim. But you should divide all implementations across different paths, as it is not wise to have more than one Firebird server working on the same security.fdb.

Multi-instance installation offers you the opportunity to predefine your installer and predefine the config files. Using the ZIP installation files simplifies the installation and deinstallation processes.

Updates via http, ftp and gds_db

There are a number of options available for sending new application updates to the end user, each with their own advantages and disadvantages.

http

Http is typically used for file download. It is simple: upload your installer software onto a web server, and anyone who can access this webserver can download the application and install it from a setup file. It is also usable when the end user is working over a proxy connection and, especially in larger companies, a lot of users are only connected to the internet via proxy connections. When the proxy setting in the company is not set to work with ftp, there is no way a user can access ftp over the proxy connection.

ftp

Ftp is really easy to use and configure and there are a lot of free ftp servers available. The main disadvantage with ftp is that in the case of broken connections you can end up with broken downloads and with a damaged file on your hard drive.

Exchanging the download files whilst people are downloading can cause problems because the ftp server typically locks the file when someone is downloading it. There aren't the transaction possibilities available when, for example, downloading from a Firebird server.

gds_db

It is also possible to download the binaries directly from a Firebird server. Simply store the data in the Firebird server in blob columns and allow the end user to access the Firebird protocol over the internet, so that he can download the update files directly from blob columns.

The advantage here is that you can simply exchange the original blob data for the new data, and any downloads that are in process at the time of replacement, will still work due to the multi-generational architecture inside Firebird.

Automated database updates: data and metadata

When the DDL and binaries are stored in a Firebird database it is simple to run automatic updates when the client is online as a unidirectional replication. This is explained in detail in the database technology article, Firebird replicated.

Server and client-backup strategies

There are a number of alternatives to automatically backup the client's database:

GBAK while the client user is working.
Copy the database when the application starts.
Copy the database when the application ends.
Upload all data to a separate storage when the user is online.

As Firebird supports hot backups it is not a problem to execute a predefined GBAK while the user is working on the database. If the database is not too large, it is not difficult to make a copy of the database every time the application is started. The only disadvantage here is that the user may have to wait longer than expected when starting his application. Making a copy of the database when the application ends only works in cases when the application is properly shut down. This of course cannot happen if the application is suddently stopped, for example because the laptop battery has run out of power. If you wish to offer a really secure solution, you can make a copy of the database when the user is online and store it in a separate place.

User-configured computers

It is important to take into consideration that end users all have differently configured computers, whether it be the operating system or existing software, such as antivirus and backup software, another Firebird server in use, or an active virus.

To discuss the various merits and issues of the various Windows operating systems would take far too long to discuss in detail here. With Windows 7 and Windows Vista it is important to be aware of the VirtualStore problem: when you think you are writing in the program directory, Windows redirects your writing operations to another place and stores them there. So it is important here to write all operations into the user directory so that all data can be retrieved should the computer suddenly crash.

If another Firebird server is running for another application on the same machine, this should not be a problem if you always use an instance for your application. Occasionally there are issues with wrong or missing msg files. If the Firebird client does not know where the firebird.msg file is, it simply reports Cannot find Firebird msg file each time a database error occurs. This can be solved by simply setting a global variable so that your database knows where to look for the firebird.msg file.

back to top of page
<< Firebird replicated | Database technology articles | Using IBExpert and Delphi applications in a Linux environment, accessing Firebird >>