Working with Embedded Server - Firebird

Windows Embedded Server has the same features as Superserver, except multi-user support and password protection. The client library is embedded in the server and this conjoined pair does the work of both client and server, for one and only one attached application.

When Embedded Server searches for the root directory of its installation, it ignores any Registry entries and the FIREBIRD environment variable. It treats as the root the folder where its binary file (fbembed.dll, renamed as fbclient.dll or gds32.dll) is located.

You should have a full set of the files required for Embedded Server under the home directory root of each embedded application. If external files are used (international language support, UDF libraries, BLOB filter libraries), Embedded Server needs to find firebird.conf under this root and, in firebird.conf, the RootDirectory parameter must point to the folder where the embedded server library file is located. For an example, see the section “Embedded Server” in Chapter Installation.

Starting an Embedded Server

The only connection protocol allowed is “Windows local.” Embedded Server does not support local loopback or any remote network protocol.

Provided the application is well configured and the server host is free of conflicts with other running Firebird servers or clients, the server process will start up as soon as the application connects successfully to a local database.


Any application that already works with a full server and a local or remote client will work with Embedded Server. Four details you need to address with your existing applications are

  • Location and naming of the Embedded Server library
  • Hard-coded database paths
  • Utilities you have written that use the remote Services Manager
  • Security or integrity implications arising from having an application interface that does not verify the user’s right to access to the server

Location and Renaming of the Library

For Embedded Server—distributed as fbembed.dll—there is no problem with renaming the library to gds32.dll or fbclient.dll, or any other name that might be needed. For the Embedded Server package to be truly self-contained, the library should be in the same directory as the application executable, and the peripheral files and directories for the server functions arranged as recommended in Chapter Installation.

If you have multiple Embedded Server applications on the same machine that need to use the library, there are choices:

  • Place a copy of the library in the “application root” of each application and set up the peripheral files and directories as recommended in Chapter Installation. This is the preferred option because it makes the “package” easy to deploy for hands-off installation independent of the surrounding filesystem structure. However, when you want to deploy multiple Embedded Server packages to the same workstation, redundancy will be a problem.
  • Place a single copy of the library at some special location—with the peripheral files and directories correctly named and placed, relative to the library—and create a Registry key to be read by each application into its library -loading arguments. This may be less attractive from the perspective of portability, but it does simplify conflict and upgrade issues.
  • Place the library—suitably named—in the system directory and use the FIREBIRD path variable to point to the root of a tree structure where the peripheral files and directories are located. This option will work only on a system that is not running a full Firebird 1.5 or higher server, and it heightens the vulnerability of the library to overwriting by other installers.

Hard-Coded Database Paths

A connection string such as WINSERVER:C:\ Program Files\ Firebird\ Firebird_1_5\employee.fdb hard-coded into your application executable is clearly going to cause problems when you deploy your software to another machine. Your code will need to adapt its connection string handling to a database location that is unknown at design time and is also constrained to be a local (not localhost) connection. This is not a problem new to the case of Embedded Server. We frequently have the need to deploy our client/server application software with provision for users or system admins to configure network and filesystem locations for production databases.

Database aliasing allows you to compile applications with “soft” filesystem paths to databases. Everywhere in the application code that refers to the path segment of the connection string uses the alias instead and the specific filesystem location becomes a matter of a localized setting in aliases.conf.

For example, suppose you decide to use EMPDATA as your alias. In aliases.conf on your development machine, you point the alias to your path:

EMPDATA = C:\Program Files\Firebird\Firebird_1_5\employee.fdb

On another machine, it might be

EMPDATA = D:\databases\employee.fdb

That takes care of the path segment and removes one level of complexity. However, you may be still left with the problem of resolving the connection protocol. Some modification will be necessary if the application is hard-coded to expect a host name and a TCP/IP or Named Pipes connection string format.

Remote Service Utilities

Utility routines using the Services API or the older Services Manager switches for remote administration may need to be disabled or adapted to work with the local connection protocol. The exact measures required will depend on what is implemented for your client/ server architecture and how it is being done currently. If your existing application provides capabilities that are restricted to protect server security and stability, you should also consider the implications of exposing the server to an application that inherently bypasses user authentication.

The Server Security Issue

Any embedded server library located on a machine that hosts databases is a potential Trojan horse. At the server level, security operates on the assumption that any user that managed to log in has been authenticated through the security database, security.fdb. However, when an embedded server attaches a client, user and password authentication are bypassed. Because any user is able to attach to any database, server security will be easily compromised if the host machine is not physically secure.

It is possible to write an embedded server application that “logs in as SYSDBA” using anything at all as the SYSDBA password. There is no way the server can tell that the SYSDBA user came in through the skylight without a valid password. If SYSDBA is active in any database, then SYSDBA is logged in and can do whatever it wants, without restriction. Anyone who has access to your network and is allowed filesystem privileges on the server could set up a malicious embedded server application that could read or write anything into any of your databases or delete them all.

Be mindful that the security database (security.fdb) is a database just like any other. SYSDBA has special SQL privileges in it—as in all databases—to create, modify, or destroy anything.

Provided the database host machine is safe from physical intrusion and unauthorized filesystem access, the “logged-in,” non-SYSDBA user in a database will be subject to the normal SQL privilege restrictions. Data object SQL privileges in Firebird databases are applied on an “opt-in” basis—no user except the SYSDBA and the database owner has automatic rights to any object in any database.

It is still necessary, therefore, to provide a way for the user (or the application, silently) to pass a user name and, desirably, a role in a conventional-looking “login” procedure. It behooves the developer to provide both the privilege protection and the gate keeping procedure.

Refer to the preceding two chapters for more information about server access security and database object SQL privileges.

Multiple Server Compatibility

Any number of embedded server applications can run simultaneously without any conflicts. However, it is not possible for multiple embedded servers to access a single database simultaneously, because of the exclusive lock that the Superserver architecture applies when the first database attachment succeeds.

Regular Firebird and InterBase servers can run simultaneously on a host machine that is running embedded servers, without conflict. For local client access, attention must be given to avoiding a namespace conflict between the regular client libraries (gds32.dll and fbclient.dll) and the name chosen for the embedded server library.

The “client” part of fbembed.dll can be a regular, remote client to other servers at the same time it is connecting internally to its embedded server.

Stopping an Embedded Server

A running embedded server cannot be stopped except by terminating the client application. Your application should terminate with the usual “housekeeping,” completing all transactions and detaching cleanly from all databases.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Firebird Topics