• on a Linux or other Unix-like server:

• on a Windows server:

Many clients also allow relative path strings (e.g. “..\examples\empbuild\employee.fdb”) but you should use these with caution, as it’s not always obvious how they will be expanded. Getting an error message is annoying enough, but applying changes to another database than you thought you were connected to may be disastrous.

Instead of a file path, the local connection string may also be a database alias that is defined in databases.conf, as mentioned earlier. The format of the alias depends only on how it’s defined in the configuration file, not on the server filesystem. Examples are:

• zappa

Upon receiving a local connection string, the Firebird client will first attempt to make a direct, embedded connection to the database file, bypassing authentication but respecting the SQL privileges and restrictions of the supplied user and/or role name. That is, if the Engine12 provider is enabled in firebird.conf or  — which it is by default. If the database file exists, but the connection fails because the client process doesn’t have the required access privileges to the file, a client-server connection is attempted (by the Loopback provider), in this order:

1. Using TCP/IP via localhost;

2. On Windows: using WNET (NetBEUI), aka Named Pipes, on the local machine;

3. On Windows: using XNET (shared memory) on the local machine.

You can force Firebird to use a certain protocol (and skip the embedded connection attempt) by prepending the protocol in URL style:

• inet://C:\Work\Databases\Drills.fdb (TCP/IP connection using an absolute path on the local Windows machine)

• wnet://doggybase (NetBEUI — named pipes — connection using an alias on the local Windows machine)

• wnet://D:\Fun\Games.fdb (NetBEUI — named pipes — connection using an absolute path on the local Windows machine)

• xnet://C:\Programmas\Firebird\Firebird_3_0\security3.fdb (XNET connection using the full path on the local Windows machine)