Revision 1.02
Pages changed in revision 1.02: 46, 59, 65, 70, 90, 93 and 112.
Index
2
Index
Index............................................................................................ 2
Dedication ................................................................................... 5
Thanks ......................................................................................... 6
About the author........................................................................ 11
Preface ....................................................................................... 12
Introduction ............................................................................... 14
Icons used .................................................................................. 15
Errata ......................................................................................... 16
Basic but essential concepts!..................................................... 17
SuperServer vs. Classic vs. SuperClassic .............................. 18
Classic (CS)....................................................................... 20
SuperServer (SS) ............................................................... 21
SuperClassic (SC) ............................................................. 22
Embedded .......................................................................... 22
What architecture to choose? ................................................ 23
32 vs. 64 bits.......................................................................... 25
Installing Firebird 3 ................................................................... 27
Installing Firebird 3 on Linux ............................................... 28
Installing Firebird on Windows® ......................................... 35
Server architecture ............................................................ 40
Service or Application? ..................................................... 40
Start automatically ............................................................ 40
Client library (fbclient.dll) ................................................ 40
gds32.dll ............................................................................ 41
Authorization for legacy Firebird clients .......................... 41
Checking whether Firebird is running............................... 43
Installing Firebird using the “Zip Kit” .............................. 46
INSTSVC .......................................................................... 46
INSTREG .......................................................................... 47
INSTCLIENT.................................................................... 48
Migrating Existing Databases to Firebird 3 .............................. 49
Why Migration? .................................................................... 50
ODS (On Disk Structure) ...................................................... 51
Test the database integrity with gbak .................................... 52
Problems with character encoding ........................................ 54
Index
3
Index
4
Index
5
Dedication
Dedication
6
Thanks
I want to thank everyone who participated in the Migration
Guide’s crowd funding campaign! Thank you for your confidence!
Choosing Firebird as the main (and the only) RDBMS used in
my applications, put me in contact with people from all over the
world, whether through emails, chats or even personally, in the
international Firebird conferences and in the Firebird Developers
Days. Many of these people ended up becoming great colleagues,
and many of them were an important part solving questions during
the writing process of this Migration Guide.
Many thanks to the core-developers Vlad Khorsun, Alex Peshkov
and Dmitry Yemanov, who were always prompt to answer my doubts.
Jiří Činčura and Mark Rotteveel for answering questions about the
.NET Provider and Jaybird issues, Paul Reeves, responsible for the
Firebird installer for Windows, Alexey Kovyazin and Dmitry Kuzmenko,
for the long-standing partnership that turned out to be a strong
friendship, and Ivan Prenosil, for the long conversations on common
interests, which often went far beyond Firebird.
Obviously, Ann Harrison, by the constant sympathy and for
always being willing to help (even with guitars and video-games )
as well for the awesome proofreading work in this book, and her
husband, Jim Starkey, for creating InterBase© and thus made Firebird
possible. Jederson Zuchi and Marcelo Daibert for helping with the
review of the Portuguese version of the book and, finally, Adriano
dos Santos Fernandes, for being the only Brazilian actively
participating in the Firebird development.
Thanks
7
Sistemas Ltda
Chrystian Sweick Silva Cigo Software de Gestao
Claudio Brasileiro Pimenta Cleverson Ruivo da Silva
Cristiano Schenatto D&O Sistemas
Daisson André dos Santos Daniel Alves Qualhato
Thanks
8
Thanks
9
Thanks
10
Thanks
11
Preface
Firebird 3.0 is the most significant new release since Firebird's
appearance in 2000. New features range from finely grained multi-
threading that allows SuperServer to exploit symmetric multi-
processors to a new security architecture that allows authentication
within a database, to encrypted communications.
Old limits on the useful length of passwords, database size, and
the total number of transactions that can be executed on a database
have been raised. Interface changes include a new object-oriented
API, provision for user-written plug-ins to extend Firebird's
capabilities, and a provider interface that simplifies engine
development and reduces the complexity of shifting between
embedded and server-based access.
Firebird 3 is faster, more secure, more capable, and more flexible
than any previous version.
Carlos Cantu has done the Firebird community a great service by
explaining how to move existing applications from earlier versions
of Firebird to Firebird 3 in clear and precise terms. Carlos has been
active with Firebird since its beginning. He has written two books
and dozens of articles about Firebird over the years. He has been
instrumental in supporting and encouraging the use of Firebird in
Brazil through the FireBase portal. When he decided to write a
migration guide to help Firebird users move their databases to
Firebird 3, more than 200 companies and individual developers
stepped up to help fund the effort. Firebird 3 is an enormous
release! Breaking the new features into groups is the only way to
understand and use them. The right place to start is explaining how
to move applications and databases from earlier Firebird versions to
Firebird 3.
Unfortunately, for the larger Firebird community, Carlos's earlier
books are available only in Portuguese, so his clear, step-by-step
instructions for getting the most from Firebird applications reached
only a small part of their potential audience. He translated this book
to English, a language available to most software developers.
Preface
13
The Migration Guide does not replace the release notes that come
with Firebird. Instead, it expands and explains a small part of what
the release notes cover, in a way that reduces the potential for
confusion and errors in moving to Firebird 3.
This book is what you need for a successful start with Firebird 3.
Ann Harrison
April/2016
Preface
14
Introduction
After a hiatus of almost 10 years, since the release of my last
book (Firebird 2), I felt it was time to write something new. After
some thinking, I decide to take the opportunity of the release of the
long-awaited Firebird 3, and help those who want to migrate their
existing servers to this new version.
The story of Firebird 3 could easily fit in a Mexican novel!
Numerous delays, broken promises, date changes, etc. made some
people doubt that Firebird 3 would ever be released! Fortunately, it's
about to happen or, perhaps, has already happened - depending on
when you read this book!
Firebird 3 brings numerous innovations, such as the long-awaited
full SuperServer’s SMP support, network and database encryption,
local user authentication in the database, improvements in the
communication protocol, in addition to several new features in
different areas of the DBMS. All this made the migration process
from an older Firebird version a bit more complicated than it was in
previous versions, where, basically, all you had to do was replace the
server with the new Firebird version or, at worst, a backup and
restore of the database. This was why I chose to write a migration
guide!
The book covers only the essential topics related to the migration
process. To stay up to date with all the news regarding Firebird 3,
including new PSQL commands, it is really important that you
read the Release Notes!
I recommend to all the readers to access www.firebirdnews.org
periodically, to stay informed about what is new in the Firebird
world.
I hope you have a pleasant reading!
Carlos H. Cantu
April/2016
Introduction
15
Icons used
In this book, you'll find several icons pointing to subjects that
deserves special attention.
Important / Tip
Icons used
16
Errata
Errors and mistakes that may be discovered after the publication
of this book will be listed in www.firebirdnews.org/migration-guide-
to-firebird-3/ along with the corrections.
I advise visiting the page periodically.
Errata
17
Database file
The use of the page cache is the first difference between the
Firebird architectures. In the SuperServer mode, all connections to
a database share the page cache among themselves. In the Classic
and SuperClassic versions, each connection has its own cache,
which is not shared. This subject is described in more detail later
in this chapter.
A second difference between Firebird operating modes is how
connections are managed: by threads or by processes and whether
requests from processes can be executed in parallel.
Classic (CS)
SuperServer (SS)
SuperClassic (SC)
Embedded
or alias, but not a remote address. As a result, you can configure the
embedded server to act as a SuperServer, Classic, or SuperClassic.
These files must be distributed with applications that use Firebird
in embedded mode:
fbclient.dll - client libary
firebird.msg - message file
ib_util.dll - memory allocation for UDFs that return data to Firebird
icudt52.dll - internationalization package
icudt52l.dat - internationalization package
icuin52.dll - internationalization package
icuuc52.dll - internationalization package
firebird.conf – if you need to use some non default configurations
databases.conf – if you wanna to use alias or define per DB config.
msvcp100.dll – if the MSVC runtime is not yet available on Windows
msvcr100.dll – if the MSVC runtime is not yet available on Windows
intl\fbintl.conf – if you use charset different to NONE
intl\fbintl.dll – if you use charset different to NONE
plugins\engine12.dll - server code
There are no hard and fast rules or "recipes" for choosing the
best architecture for every imaginable situation. Many variables and
special needs influence the choice of the most suitable architecture
for each installation.
However, here is a "general guide" that can serve as the basis for
choosing among the architectures. Your needs may not fit in this
"recipe". The recipe assumes that the hardware and operating
system of the server are configured correctly.
32 vs. 64 bits
Installing Firebird 3
Learn how to install Firebird 3 on Linux and Windows.
Installing Firebird 3
28
Installing Firebird 3
29
Installing Firebird 3
30
Installing Firebird 3
31
The installer asks you for the SYSDBA password. This example
used the password masterkey, which was the default password for the
SYSDBA account for decades. Never use that password in
production servers. It is widely known and therefore very insecure.
If everything went fine, the installation finishes with “Install
completed” message.
Installing Firebird 3
32
./bin/isql employee
Statement failed, SQLSTATE = 08006
Can not access lock files directory /tmp/firebird/
Use CONNECT or CREATE DATABASE to specify a database
SQL> quit;
If you see that error, your login does not have sufficient rights to
create an embedded connection to Firebird. Because there was no
host name in the command line, Firebird attempted to create an
embedded connection, rather than a network connection over tcp/ip.
Remember an embedded connection does not validate the user and
password.
Installing Firebird 3
33
Installing Firebird 3
34
Installing Firebird 3
35
Installing Firebird 3
36
The next screen displays the Firebird license. Accept it and click
Next to continue.
Installing Firebird 3
37
Installing Firebird 3
38
In the following step, you choose among the four different types
of installation:
Installing Firebird 3
39
Installing Firebird 3
40
Server architecture
Service or Application?
Unless you have a very specific reason not to, you should run
Firebird as a Service, which is the default mode. Running Firebird
as a service avoids the need to log in on Windows and start Firebird,
with the chance of starting it from the wrong account. Running
Firebird as a Service eliminates the need for the Firebird Guardian.
Running Firebird as an Application on development systems can
make it easier to start and stop Firebird frequently. Having the
Firebird icon on the Windows taskbar also makes development
easier.
Start automatically
Installing Firebird 3
41
gds32.dll
Installing Firebird 3
42
Installing Firebird 3
43
Finally, you can choose to start Firebird server and open the
“What’s next” page, which requires an Internet connection.
Installing Firebird 3
44
Firebird’s instsvc utility, with the “q” option can also verify the
service status:
C:\Firebird3>instsvc q
Firebird Server - DefaultInstance IS installed.
Status : running
Path : C:\Firebird3\firebird.exe -s DefaultInstance
Startup : automatic
Run as : LocalSystem
Installing Firebird 3
45
Otherwise, you see isql prompt, indicating that the Firebird server
is operational. The show tables command lists the tables of the
database, proving that the connection is live:
Database: localhost:employee, User: SYSDBA
SQL> show tables;
COUNTRY CUSTOMER
DEPARTMENT EMPLOYEE
EMPLOYEE_PROJECT JOB
PROJECT PROJ_DEPT_BUDGET
SALARY_HISTORY SALES
In Windows XP:
netsh firewall add portopening protocol=TCP
port=3050 name="Firebird" mode=ENABLE scope=SUBNET
Installing Firebird 3
46
The Zip Kit is simply the directory structure and files necessary to
run the Firebird server, compressed into a single zip file. You can
find it on the Downloads page of the Firebird official site,
firebirdsql.org.
In some cases, installing Firebird using the installer is too
restrictive. The installer cannot allow you to run more than one
Firebird version on a single computer.
Unpacking the Zip Kit is only the start of the installation process.
The Firebird kit includes utilities that help you complete the
configuration: instsvc, instreg and instclient.
INSTSVC
Installing Firebird 3
47
instsvc stop
Service "Firebird Server - DefaultInstance" successfully stopped.
INSTREG
The instreg.exe utility modifies the Windows registry, creating the
Firebird default key (HKLM\SOFTWARE\Firebird Project\Firebird
Server\Instances), which points to the Firebird installation directory.
The server process does not require this key, but a number of client
applications, including Firebird's own utilities, use this key to find
the Firebird directories.
Installing Firebird 3
48
Where:
INSTCLIENT
Installing Firebird 3
49
Migrating Existing
Databases to
Firebird 3
Why Migration?
Firebird ODS
1.0 10.0
1.5 10.1
2.0 11.0
2.1 11.1
2.5 11.2
3.0 12.0
database file on the server, and backupfile is the full path to the
backup file to be generated on the server:
gbak -user user -pas password -b -v -g -se service_mgr database
backupfile
If gfix reports transactions in limbo, run it again, this time using the
-mend switch.
Once you have a good backup, restore it:
gbak -user user -pas password -c -v -se service_mgr backupfile
database
If you are running Firebird 2.1 or later, you should check for
malformed strings while you are validating that you can backup and
restore the database. The next section describes that check.
If you currently run Firebird 2.1 or later, you should perform this
check before starting to migrate to Firebird 3. If you are using an
older version of Firebird that mishandles conversions from other
character sets to UNICODE_FSS, you can wait until the migration
step to perform this check and correct errors.
Firebird uses the character set UNICODE_FSS to store the data
in the system tables (RDB$...), strings, and source code of objects like
procedures, triggers, etc.
Before Firebird 2.1, bugs in Firebird caused it not to convert
multi-byte character sets sent by the client to UNICODE_FSS. As a
result, that data was stored in an invalid format in columns declared
as unicode_fss, whether in user data or metadata.
The Firebird 2.1 release refused to accept those malformed strings.
If a database incorrectly coded metadata strings, restoring a backup
reports an error about malformed strings, either for metadata problems
or for data, for example:
gbak: ERROR:Malformed string
gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option.
Remember: use these switches only if the first try to run the
restore had failed due to “malformed string” errors! If you use them
when they are not needed, you can corrupt the database.
Note that the reserved words CORR and OFFSET appear in the
script enclosed in double quotes ("") making them quoted
identifiers, but only when they are the names of tables, fields,
procedures, etc. that are being defined. Gbak restore does not "auto-
correct" when recreating the source code of the TEST stored
procedure, which references the reserved words CORR and OVER!
The TEST procedure runs successfully in Firebird 3, because the
backup/restore process preserves the BLR (B inary L anguage
R epresentation) version of the procedure created on the previous
1. Stop Firebird.
2. Rename the original database file to avoid new
connections to modify the data.
3. Start Firebird.
4. Backup with gbak:
gbak -user user -pas password -b -v -g -se
service_mgr database backupfile
Install and start Firebird 3. If you are keeping the same server
machine, uninstall the earlier version of Firebird before installing
Firebird 3. If you want to keep both versions of Firebird available
on the same server, the simplest solution is to disable/remove the
older service while running Firebird 3. If you want to run both
versions concurrently, you must configure them manually, setting
Users in
Firebird 3
Firebird 3 introduces big changes in users management and in the
role of the SYSDBA user. Be prepared to revisit your assumptions.
Users in
Firebird 3
63
Local users
Users in
Firebird 3
64
Firebird 3 also allows you to give the security database any name
you want. You can decide that your central user database will be
centralusers.fdb, instead of the default security3.fdb, and put it in any
directory on the server, not just the Firebird installation directory.
To support these new capabilities, Firebird added a new
parameter SecurityDatabase . By default, this parameter is defined
in the firebird.conf file as $(root)/security3.fdb, which declares that the
security database is stored in the root of the Firebird installation
and called security3.fdb. SecurityDatabase can also be set per
database in the databases.conf file, previously called aliases.conf,
allowing you to specify a different security file for every database!
Below we have an example of a databases.conf file defining three
aliases for three databases: base1, base2 and base3. Base1 is
configured so that its user information is stored in the file
c:\DBUsers\users_base1.fdb. Base2 is configured so that its user
information is stored locally, meaning that users is managed within
the database itself. For base3, only the alias is defined, so its user
information is stored in the default security database, defined in
firebird.conf.
base1 = c:\databases\base1.fdb
{
SecurityDatabase = c:\dbUsers\users_base1.fdb
}
base2 = c:\dbs\base2.fdb
{
SecurityDatabase = base2
}
base3 = c:\dbs\base3.fdb
Users in
Firebird 3
65
Note the need to enter the isql using the command line switch
-user sysdba, even if no sysdba exists yet.
Now you have a security database, but it has no users at all, not
even the SYSDBA! The next step is to create the SYSDBA – or any
other desired user – in that database:
SQL> connect base1;
SQL> create user SYSDBA password 'mypassword’;
SQL> commit;
SQL> exit;
Passwords
Users in
Firebird 3
66
Users in
Firebird 3
67
The Firebird installer allows you to create the SYSDBA user and
set its password during the installation. However, if a problem
occurs during the creation of the security database, or if you are not
using the installer, then the security database will be "empty" - no
users defined, not even the SYSDBA.
You can initialize the security database in two ways, creating, for
example, a SYSDBA user.
The first one uses the gsec utility, using these steps:
Users in
Firebird 3
68
Note that we call isql passing only employee, instead of the full path
to the employee.fdb database. Firebird 3 predefines the alias employee in
databases.conf pointing to the sample database. The installation
process configures employee.fdb to use the default security database,
so the SYSDBA user you just created is stored in the database
security3.fdb in the Firebird root directory and can access all databases
that use that security database.
Whenever a user is created with the name SYSDBA, that user
automatically gets administrator rights, so you do not need to assign
the role RDB$ADMIN to that account.
Users in
Firebird 3
69
CREATE OR ALTER USER name SET [PASSWORD ‘apassword’] [options]
[ TAGS ( tag [, tag [, tag ...]] ) ] [USING PLUGIN name]
DROP USER name [USING PLUGIN name];
Creating users
Create a new user with either the create user or create or alter user
statement.
When creating a user, you must include at least a password for
that user. Other attributes, such as firstname, active, etc. are optional.
Firebird3 allows you to enable or disable users and define tags by
assigning a name and a value to them. A disabled user continues to
exist in the security database, but cannot login. During the creation
of the user, you can choose to create it as enabled or disabled using
the active or inactive clauses.
Users in
Firebird 3
70
This command creates the user Albert and specifies two tags. The
first tag is degree and set to 'genius'. The second tag is specialty and set
to 'math'. Tags are associated with the user (Albert) and can be
queried, modified, or removed when necessary.
Users in
Firebird 3
71
Modifying users
Only the SYSDBA or a user assigned and logged in with the role
rdb$admin for this database can alter other users. "Normal" users can
change only their own password, first name, middle name, last name, and
tags.
Examples of altering users:
alter user albert active; -- enable user albert.
alter user albert set tags (drop specialty); -- Removes the tag
"specialty" for the user albert.
Deleting users
Users in
Firebird 3
72
Where:
sec$user_name – stores the user name;
sec$key – stores the tag name;
sec$value – stores the tag’s value;
sec$plugin – stores the name of the user management plugin;
Below we can see the result of the same select, this time run by the
user Albert, logged in without the rdb$admin role, in other words,
Users in
Firebird 3
74
Next, we can see the result of the same select, executed again by
user Albert, but this time logged in with the role rdb$admin:
LOGIN TAG VALUE PLUGIN
==================== =========== =========== ==================
SYSDBA <null> <null> Srp
SYSDBA <null> <null> Legacy_UserManager
ALBERT SPECIALTY math Srp
ALBERT DEGREE genius Srp
JOHN <null> <null> Srp
Did you notice that the result is exactly the same as when the
sysdba ran the statement? Assigning the role rdb$admin to a “normal”
user gives him the power of the SYSDBA.
• Default: : security3.fdb;
• Self:: the database stores the users locally;
• Other: a specific non-default security
database;
Users in
Firebird 3
75
Redirect gsec output to a text file, and edit this file to preserve
only the names of the users. Manually insert the CREATE USER
stataments, line by line, resulting in a script like this:
create user JOHN password ‘john_password’;
create user JOSEPH password ‘joseph_password’;
create user MARY password ‘mary_password’;
commit; -- Don’t forget to COMMIT!
Users in
Firebird 3
76
coalesce(' firstname ''' || R.RDB$FIRST_NAME || '''', '') ||
coalesce(' middlename ''' || R.RDB$MIDDLE_NAME || '''', '') ||
coalesce(' lastname ''' || R.RDB$LAST_NAME || '''', '') || ';'
from RDB$USERS R;
This method has the advantage of allowing you to extract the first
name, middle name, and last name, when this information exists. In
addition, you can assign each created user a new "random"
password. In the example, a numeric random password will be
generated for each user, by using the built-in function RAND(). The
result would be something like:
create user SYSDBA password '871892958' firstname 'Sql'
middlename 'Server' lastname 'Administrator';
create user JOHN password '671411450';
create user JOSEPH password '723543343';
create user MARY password '140440819';
commit; -- Don’t forget to COMMIT!
Users in
Firebird 3
77
Legacy_UserManager.
Here is the user migration script with some comments about what
is being done:
set term ^;
execute BLOCK returns(USR varchar(31), PASSWD varchar(36))
as
declare variable FRST varchar(32);
declare variable MDDL varchar(32);
declare variable LST varchar(32);
declare variable ATTR varchar(4096);
declare variable SQL varchar(4096);
declare variable UID int;
declare variable GID int;
begin
-- Retrieve the fields related to the full name of the user
for select RDB$USER_NAME, RDB$FIRST_NAME, RDB$MIDDLE_NAME,
RDB$LAST_NAME,
RDB$UID, RDB$GID, UUID_TO_CHAR(GEN_UUID())
from RDB$USERS
where RDB$USER_NAME is not null and
upper(RDB$USER_NAME) != 'SYSDBA' – skip SYSDBA
into :USR, :FRST, :MDDL, :LST, :UID, :GID, :PASSWD
do
begin
-- Assembly the SQL statament for user creation
SQL = 'create or alter user ' || USR || ' password ''' ||
PASSWD || '''';
if (FRST is not null) then
SQL = SQL || ' firstname ''' || FRST || '''';
if (MDDL is not null) then
Users in
Firebird 3
78
SQL = SQL || ' middlename ''' || MDDL || '''';
if (LST is not null) then
SQL = SQL || ' lastname ''' || LST || '''';
SQL = SQL || ' active';
-- retrieve the GID if it exists
ATTR = '';
if (UID is not null) then
ATTR = 'uid=''' || UID || '''';
if (GID is not null) then
begin
if (char_length(ATTR) > 0) then
ATTR = ATTR || ', ';
ATTR = ATTR || 'gid=''' || GID || '''';
end
if (char_length(ATTR) > 0) then
begin
SQL = SQL || ' tags (' || ATTR || ')';
end
execute statement SQL; -- creates the user
suspend; -- returns the user and generated password
end
end^
commit ^
exit ^
The script reads the existing users on the old security database,
retrieving the names and attributes, and creates those same users in
Firebird 3, with a random password generated by the internal gen_uuid
function. When executed, the script will display the names of the
users and their generated passwords. Note that the script is
configured not to migrate the SYSDBA user.
Choose the whichever migration method best suits your needs.
Users in
Firebird 3
79
The first tip seems silly, but I have seen an enormous number of
servers where whoever installed Firebird didn't even bother to
change the default SYSBDA password. So let me scream out loud:
never install the Firebird using the masterkey password! Any
idiot with internet access knows that password.
Furthermore, a Firebird database file must be accessible only
by the Firebird process and the system administrator. Right!
Client applications do not need physical access to the database.
"Ordinary" users do not need and should not have physical access
rights to the database file. Restricting access prevents copying the
database for attack.
Therefore, as soon as you have configured a Firebird server, you
should restrict access to the database files, preventing thieves from
copying them.
You must protect your backup files too! There's no point in
restricting access to the database files if you store your
backups in public directories, or write them to CDs/DVDs left
lying on your desk.
Key stored in external device (i.e. pen drive, usb token, etc):
Hacker steals the device and the plug-in library,
and has your data.
available, anyone can download it, study it, figure out how it handles
keys, etc. making it ineffective, or giving a false sense of security.
Therefore, developers should create their own encryption plug-
ins, making every effort to handle the key securely. In a near future,
companies will offer encryption plug-in solutions, making the life
easier for those who do not want to create their own.
Although a Firebird installation doesn't create a default
encryption plug-in, it includes a sample plug-in in C++ called
DbCrypt.cpp, located in the examples\dbcrypt subdirectory.
The Firebird 3 Crypto API includes methods for providing the
cryptographic key via the client application, sending the key from the
client to Firebird across the network in an encrypted connection,
obviously. An example of this technique can be seen in the
CryptKeyHolder.cpp file, also available in the examples\dbcrypt directory.
Note, however, that an experienced hacker could create a custom
version of Firebird that collects passwords and keys in a file or even
in the firebird.log.
Firebird 3 includes special commands that allow you to encrypt
and decrypt databases "on the fly", without exclusive access to the
database file. When encryption is activated, Firebird will start
encrypting the database in background. The process is transparent
to end users.
Conclusion
To guarantee that no one can steal your data, follow these steps:
If you take step 4 seriously, you can keep malicious people out of
your data.
Wire Protocol
Enhancements
Traffic encryption, compression and optimizations
Traffic encryption
Client Server
Disabled Enabled Required
Disabled Disabled Disabled Rejected
Enabled Disabled Active Active
Required Rejected Active Active
Encryption status based on the configuration of the WireCrypt parameter in client
and server. The highlighted options are the default.
Source: http://www.javamex.com/tutorials/cryptography/ciphers.shtml
Traffic compression
Connection strings
Learn how to specify the transport protocol, ports, and service name
and how to use IPv6 address, etc. to establish a connection.
Connection strings
96
Legacy syntax
The path to the database file follows the rules of the host
operating system. For example, on posix systems, the path is case
sensitive.
Here are several examples of connection strings, some of them taken
from the Firebird 3 Release Notes:
Connection strings
97
Local connections:
/db/mydb.fdb
C:\db\mydb.fdb
mydb
Connection strings
98
Where:
INET = TCP/IP
WNET = NetBeui (named pipes)
XNET = Local connection via shared memory
Using the URL syntax, you can specify exactly how you want to
make the connection with Firebird, as in the following examples:
Connection strings
99
Connection strings
100
connection request using the string above, it runs through the list of
providers, from left to right, until it finds a provider that recognizes
and creates the connection.
In this example, the first provider (Remote) fails, since there is no
host name in the string. The connection request then goes to the
second provider (Engine12), which establishes an embedded
connection.
However, what do you do to make an xnet connection rather
than an embedded connection? In that case, you must specify the
xnet protocol in the connection string:
xnet://c:\databases\base.fdb
Connection strings
101
IPv6 support
Connection strings
102
Firebird 3 and
legacy applications
What should you check in your applications, so they work well with
Firebird 3?
.NET applications
When this book was written, the Firebird .NET Provider did not
yet support the new communication protocol encryption or SRP
authentication, which are the default on Firebird 3.
The .NET Provider implements the Firebird communication
protocol natively. It does not depend on the client library (fbclient) to
communicate with the server. Therefore, it needs its own
implementation of the updated wire protocol to support new
features like encryption, compression and SRP authentication.
To connect to Firebird 3 with an application using the .NET
Provider, you need to set the following parameters in firebird.conf:
WireCrypt = enabled
The default value for AuthServer is SRP. However, for the .NET
Provider to connect to Firebird 3, you must change to the "legacy"
authentication, even though it is less secure. You can set the
AuthServer configuration for specific databases using the
databases.conf file.
Jaybird applications
You should use the same version of the Firebird client library as
the installed server so you can take advantage of new features. If
you need to connect to Firebird 3 using an "old" fbclient, you must
configure the firebird.conf file to use legacy authentication and to
accept connections without encryption:
WireCrypt = enabled
AuthServer = Legacy_Auth, Srp, Win_Sspi
Query performance
Reserved words
These scripts delete the source code of the user defined procedures
and triggers of a database.
update RDB$PROCEDURES
set RDB$PROCEDURE_SOURCE = null
where ((RDB$SYSTEM_FLAG = 0) or (RDB$SYSTEM_FLAG is null));
commit;
update RDB$TRIGGERS T
set T.RDB$TRIGGER_SOURCE = null
where ((T.RDB$SYSTEM_FLAG = 0) or (T.RDB$SYSTEM_FLAG is null))
and
not exists(select C.RDB$TRIGGER_NAME
from RDB$CHECK_CONSTRAINTS C
where C.RDB$TRIGGER_NAME =
T.RDB$TRIGGER_NAME);
commit;
You can download a trial version of HQBird and its User Guide
from the IBSurgeon official site www.ibsurgeon.com.
Even though there's only one user connected to the database, the
count returned 3. In the second select, you see that the other two
connections have the field mon$system_flag set to 1, indicating that
they are are system connections, created by Firebird itself and not
by a regular user.
To get the list or the number of active users at any given time,
use the command below:
SQL> select count(*) from mon$attachments
where mon$system_flag = 0;
COUNT
========
1
Appendix
Appendix
115
Macros
Firebird provides a series of macros to simplify references to
directories in the configuration files. The syntax is $(macro_name).
$(root)
Root installation directory of Firebird.
$(install)
Directory where Firebird was installed. Initially, $(install) and $(root)
are the same. However, $(root) can be overridden by setting the
FIREBIRD environment variable.
$(this)
Directory where the current configuration file is stored.
$(dir_conf)
Directory where firebird.conf and databases.conf are located.
$(dir_secdb)
Directory where the security database is located.
$(dir_plugins)
Directory where plug-ins are located.
$(dir_udf)
Default directory for UDFs.
$(dir_sample)
Directory where sample files are stored.
$(dir_sampledb)
Directory where the sample database (employee.fdb) is stored.
$(dir_intl)
Directory where the internationalization modules are located.
$(dir_msg)
Directory where the message file, firebird.msg, is stored. Normally this
is the same as $(root), but can be overridden by the FIREBIRD_MSG
environment variable.
Appendix
116
Note that you can include one configuration file inside another,
using the “include” directive, i.e.:
include my_files.conf
The relative path on the include clause starts from the directory
where the configuration file containing the include directive is stored.
The wildcards (* and ?) are recognized by the include directive,
allowing you to include files matching the mask, for example:
include $(dir_plugins)/config/*.conf
The above example would include all the files with the .conf
extension, located in the config subdirectory of the plug-ins directory.
Configuration entries
Appendix
117
Appendix
118
Glossary
BDE: Borland Database Engine, which allows access to many
databases, including dBase, Paradox, InterBase, SQLServer, Oracle,
etc. Projects developed with the Borland programming languages
such as Delphi, CBuilder, etc. made extensive use of BDE, which
made developer’s life easier, at a cost in performance, because BDE
could not exploit DBMS specific features. BDE is currently
discontinued.
BLR: Again, the term BLR was not an acronym although the
letters happen to be the initials of the manager of the Rdb/ELN
project at DEC. By design, BLR was a single format that could
represent queries in SQL, or the extinct QUEL and GDML
languages. Now it carries the retronym Binary Language
Representation and is the language used inside the Firebird engine.
Procedures, triggers, views, etc. are compiled into BLR, and stored
in the database.
Glossary
119
application that handles more than one language, consider using the
universal encoding UTF-8 even though it uses more space than a
character set designed for a specific language.
Glossary
120
Glossary
121
Glossary
122
Glossary
123
Glossary
124
Glossary