the database experts

Firebird-Datenbankreplikation

Zuverlässige Synchronisation nahezu in Echtzeit für unternehmenskritische Systeme

Holger Klemt, August 2026

Moderne Anwendungen stellen zunehmend Anforderungen an Datenbanken, die über mehrere Standorte, Server und Umgebungen hinweg kontinuierlich verfügbar sein müssen. Ob Hochverfügbarkeit, die Migration von einer Desktop-Anwendung zu einer webbasierten Lösung, verteilte Datenbanken oder die kontinuierliche Synchronisierung zwischen verschiedenen Rechenzentren – eine zuverlässige Datenbankreplikation ist dabei ein entscheidender Bestandteil.

Unsere Firebird-Replikationslösung wurde genau für solche Szenarien entwickelt. Sie kombiniert transaktionssichere Replikation, Synchronisierung nahezu in Echtzeit, One-to-Many-Replikation und Unterstützung für große Firebird-Datenbanken – und kann in bestehende Produktionsumgebungen integriert werden, ohne die Datenbank offline nehmen zu müssen.

Entwickelt für Firebird

Das Replikationsframework unterstützt Firebird 2.5 und neuere Versionen, einschließlich Firebird 4, Firebird 5 und aktuellen Firebird 6 Datenbanken.

Ein wesentlicher Vorteil besteht darin, dass die Replikation direkt auf Datenbankebene mithilfe von aktiven Triggern und einem Transaktionsprotokoll umgesetzt wird. Änderungen an der Quelldatenbank werden als Transaktionen erfasst und können anschließend an eine oder mehrere Ziel-Datenbanken übertragen werden.

Diese Architektur stellt sicher, dass Änderungen nicht verloren gehen, wenn beispielsweise eine Netzwerkverbindung oder der Replikationsprozess vorübergehend nicht verfügbar ist.

Replikation ohne Ausfallzeit der Produktionsdatenbank

Eine der wichtigsten Anforderungen bei Migrations- oder Hochverfügbarkeitsprojekten besteht darin, die Replikation aktivieren zu können, ohne den laufenden Betrieb der Anwendung zu unterbrechen.

Unser Replikationsverfahren ist genau auf dieses Szenario ausgelegt.

Sobald die Replikation initialisiert wurde, beginnen die erforderlichen Trigger damit, INSERT-, UPDATE- und DELETE-Operationen in einem dedizierten Transaktionsprotokoll zu erfassen. Die Produktionsdatenbank läuft weiterhin einwandfrei.

Die initiale Synchronisierung erfolgt anschließend durch die Erstellung eines Backups der Master-Datenbank und dessen Wiederherstellung auf dem Zielserver. Auch hierfür muss die Produktionsdatenbank nicht offline genommen werden.

Nachdem die Ziel-Datenbank initialisiert wurde, überträgt der Replikationsprozess alle Transaktionen, die während der Erstellung des Backups entstanden sind, und setzt anschließend die kontinuierliche Synchronisierung mit allen neuen Transaktionen fort.

Transaktionssichere Replikation

Zuverlässigkeit steht im Mittelpunkt der Architektur.

Angenommen, die Master-Datenbank hat 100 Transaktionen gesammelt, die noch repliziert werden müssen. Fällt die Netzwerkverbindung aus, nachdem nur ein Teil der Daten übertragen wurde, gehen die verbleibenden Transaktionen nicht verloren.

Sie bleiben im Transaktionsprotokoll gespeichert und werden beim nächsten Replikationsvorgang erneut berücksichtigt.

Der Replikationsprozess ist daher nicht auf eine dauerhaft verfügbare Netzwerkverbindung angewiesen. Ein Zielserver kann sogar über mehrere Tage oder Wochen nicht verfügbar sein, während die Master-Datenbank weiterhin alle für die spätere Synchronisierung erforderlichen Transaktionen erfasst.

Sobald das Zielsystem wieder erreichbar ist, wird die Replikation an der Stelle fortgesetzt, an der sie unterbrochen wurde.

One-to-Many-Replikation

Die Architektur unterstützt auch die One-to-Many-Replikation.

Eine einzelne Master-Datenbank kann ihre Daten an mehrere Zielserver replizieren. Dabei wird jedes Zielsystem unabhängig verwaltet und überwacht.

Beispielsweise:

Master-Server → Slave 1
Master-Server → Slave 2
Master-Server → Slave 3

Ist beispielsweise Slave 2 vorübergehend nicht verfügbar, kann die Replikation zu Slave 1 und Slave 3 normal weiterlaufen. Die für Slave 2 erforderlichen Transaktionen bleiben auf dem Master verfügbar, bis dieses Zielsystem wieder erreichbar ist.

Dadurch eignet sich die Architektur besonders für verteilte Systeme, bei denen einzelne Standorte über unzuverlässige Netzwerkverbindungen verfügen oder Server zeitweise nicht verfügbar sind.

Multi-Master-Replikation

Abhängig von der Struktur der Datenbank kann die Technologie auch eine Multi-Master-Replikation unterstützen.

In einer solchen Konfiguration können mehrere Server als Master-Datenbanken arbeiten und Änderungen untereinander austauschen.

Multi-Master-Umgebungen erfordern jedoch eine sorgfältige Betrachtung des Datenbankdesigns, insbesondere bei der Generierung von Primärschlüsseln. Automatisch generierte Schlüssel müssen beispielsweise so gestaltet sein, dass unabhängig auf verschiedenen Master-Servern erzeugte Datensätze nicht zu Schlüsselkonflikten führen.

Falls erforderlich, können Datenbank-Metadaten und Anwendungslogik entsprechend angepasst werden, um eine solche Architektur zu unterstützen.

Synchronisierung nahezu in Echtzeit

Der Replikationsprozess ist für einen Betrieb nahezu in Echtzeit ausgelegt.

In einer typischen Umgebung werden Transaktionen kontinuierlich über einen Push/Pull-Prozess übertragen. Die tatsächliche Latenz hängt dabei von der Leistungsfähigkeit der Server, dem Transaktionsvolumen und den Netzwerkbedingungen ab.

In einer großen verteilten Installation waren Änderungen an entfernten Standorten typischerweise innerhalb von weniger als 10 Sekunden verfügbar. Selbst bei hoher Systemlast lag die Verzögerung in der Regel bei etwa einer Minute.

Auch Standorte mit langsameren oder zeitweise unzuverlässigen Internetverbindungen konnten weiterhin lokal arbeiten. Sobald die Verbindung wiederhergestellt war, wurden die aufgelaufenen Transaktionen automatisch synchronisiert.

Bewährt bei großen und verteilten Firebird-Installationen

Die Technologie wurde bereits in anspruchsvollen Produktivumgebungen mit großen Datenbanken und geografisch verteilten Systemen eingesetzt.

Ein besonders umfangreiches Projekt umfasste:

9 zentrale Server
6 verschiedene Rechenzentren und Städte
Rund 225 Firebird-Datenbanken an einzelnen Standorten
Etwa 500 GB für die größte zentrale Datenbank
Rund 2 Milliarden Datensätze in der größten Datenbank
Etwa 5–6 Millionen INSERT-, UPDATE- und DELETE-Operationen pro Tag
Synchronisierung nahezu in Echtzeit zwischen den zentralen Systemen und den einzelnen Standorten

Die einzelnen Datenbanken an den entfernten Standorten enthielten jeweils Teilmengen der zentralen Daten und übertrugen lokale Änderungen zurück an die zentrale Infrastruktur.

Auch bei unzuverlässigen Netzwerkverbindungen an einzelnen Standorten stellte die Replikationsarchitektur sicher, dass Transaktionen solange verfügbar blieben, bis sie erfolgreich übertragen werden konnten.

Umgang mit sehr großen Datenbanken und BLOB-Daten

Große Firebird-Datenbanken können erhebliche Mengen an BLOB-Daten enthalten, insbesondere in Anwendungen aus Bereichen wie Gesundheitswesen, Dokumentenmanagement, Bildverarbeitung oder Archivierung.

In einer anderen Installation erreichte die gesamte Datenbankumgebung einschließlich Transaktions-protokollen und jährlicher BLOB-Datenbanken eine Größe von rund 7 TB.

Bei sehr großen Datenmengen kann es sinnvoll sein, historische Daten in separate Datenbanken auszulagern.

Beispielsweise können jährliche Transaktions- oder BLOB-Datenbanken nach Abschluss eines Geschäftsjahres geschlossen und schreibgeschützt werden. Sie bleiben weiterhin über die Hauptdatenbank zugänglich, vergrößern jedoch nicht mehr die aktive Produktionsdatenbank.

Dieser Ansatz kann zukünftige Backup- und Restore-Vorgänge erheblich vereinfachen und beschleunigen.

Kein Single Point of Failure im Replikationsprozess

Ein vorübergehender Ausfall eines Zielservers oder einer Netzwerkverbindung führt nicht dazu, dass die Master-Datenbank keine Änderungen mehr erfassen kann.

Dies ist insbesondere bei verteilten Installationen von großer Bedeutung.

Ein entfernter Server kann neu gestartet werden, die Netzwerkverbindung verlieren oder über einen längeren Zeitraum nicht verfügbar sein. Sobald er wieder erreichbar ist, kann der Replikationsprozess mit den Transaktionen fortgesetzt werden, die während seiner Abwesenheit im Transaktionsprotokoll gespeichert wurden.

Das Ergebnis ist eine Replikationsarchitektur, die auf zuverlässiger nachträglicher Synchronisierung ohne Datenverlust basiert und nicht voraussetzt, dass alle Server und Netzwerkverbindungen jederzeit verfügbar sind.

Die Datenbank-Metadaten spielen eine entscheidende Rolle

Eine zuverlässige Replikation beginnt mit einem geeigneten Datenbankdesign.

Idealerweise verfügt jede Tabelle, die repliziert werden soll, über einen Primärschlüssel oder zumindest über einen geeigneten eindeutigen Index.

Auch Primärschlüssel sollten möglichst kompakt sein. Extrem komplexe Primärschlüssel, die sich über eine große Anzahl von Spalten erstrecken, können die Replikation und die Entwicklung der Anwendung unnötig komplizieren.

Tabellen ohne Primärschlüssel benötigen gegebenenfalls einen alternativen Mechanismus zur eindeutigen Identifizierung von Datensätzen. Abhängig von der Struktur der Datenbank kann hierfür eine Technologie auf Basis von Firebirds RDB$DB_KEY in Betracht gezogen werden.

Bei komplexen Datenbankumgebungen können die Metadaten bereits vor Beginn der Implementierung analysiert werden, um die geeignete Replikationsstrategie zu bestimmen.

Kontinuierliche Replikation mit geringem Wartungsaufwand

Nach der Implementierung arbeitet das Replikationssystem weitgehend im Hintergrund.

In vielen Installationen ist keine regelmäßige manuelle Wartung erforderlich.

Dennoch kann es vorkommen, dass Datenbankadministratoren umfangreiche Änderungen an den Metadaten oder der Datenbankstruktur durchführen. In solchen Fällen kann es erforderlich sein, die Replikation neu zu initialisieren oder anzupassen.

Für diese Situationen kann technische Unterstützung über ein Prepaid-Support- und Hotline-System bereitgestellt werden. Administratoren können dadurch bei Bedarf Unterstützung anfordern, ohne einen permanenten Wartungsvertrag ausschließlich für gelegentliche Replikationsvorgänge abschließen zu müssen.

Implementierung und Migration

Jedes Replikationsprojekt ist unterschiedlich. Die Größe einer Datenbank allein reicht daher nicht aus, um den tatsächlichen Implementierungsaufwand zu bestimmen.

Vor Beginn eines Projekts empfehlen wir daher eine Analyse der folgenden Punkte:

Datenbank-Metadaten
Primärschlüssel und Indizes
Datenbankstatistiken
Anzahl und Größe der Datenbanken
Transaktionsvolumen
Verwendung von BLOB-Daten
Netzwerkarchitektur
Anzahl der Replikationsziele
Gewünschte Replikationsrichtung
Anforderungen an Verfügbarkeit und Wiederherstellung

Für eine erste technische Bewertung genügt häufig bereits ein Metadata-Only-Backup. Dadurch kann die Struktur der Datenbank analysiert werden, ohne dass sensible Kundendaten bereitgestellt werden müssen.

Die Implementierung und Schulung können vollständig remote durchgeführt werden – auch bei Kunden in weit entfernten Zeitzonen.

Quellcode und Anpassungsmöglichkeiten

Das Replikationsframework kann zusammen mit seinem Quellcode bereitgestellt werden. Dadurch haben Kunden die Möglichkeit, die Funktionsweise nachzuvollziehen, Anpassungen vorzunehmen und die Lösung in ihre bestehende Systemumgebung zu integrieren.

Dies ist insbesondere dann von Vorteil, wenn die Replikation Teil eines größeren Migrationsprojekts ist, beispielsweise bei der Umstellung einer bestehenden Desktop-Anwendung auf eine webbasierte Architektur, während das bestehende Produktivsystem weiterhin verfügbar bleiben soll.

Eine praktische Grundlage für die Systemmigration

Datenbankreplikation ist besonders wertvoll, wenn ein Unternehmen eine bestehende Anwendung modernisieren möchte, ohne längere Ausfallzeiten in Kauf nehmen zu müssen.

Beispielsweise kann ein Krankenhausinformationssystem (KIS) zusammen mit einer zugehörigen Bilddatenbank kontinuierlich verfügbar bleiben müssen, während die bestehende Desktop-Anwendung schrittweise auf eine moderne Webanwendung migriert wird.

Eine transaktionsbasierte Replikationsschicht kann dabei als Brücke zwischen der bestehenden und der neuen Systemumgebung dienen. Beide Systeme können parallel betrieben werden, während die Daten kontinuierlich synchronisiert werden.

Dadurch lassen sich Migrationsrisiken erheblich verringern und ein kontrollierter Übergang anstelle einer disruptiven „Big-Bang“-Migration ermöglichen.

Eine Lösung, die auf langjähriger Praxiserfahrung basiert

Die hier beschriebene Architektur wurde nicht nur für theoretische Szenarien entwickelt. Sie wird seit mehr als einem Jahrzehnt in anspruchsvollen Produktivumgebungen mit geografisch verteilten Firebird-Datenbanken, großen Transaktionsvolumina, unzuverlässigen Netzwerkverbindungen und erheblichen Datenmengen eingesetzt.

Die Kombination aus Transaktionsprotokollierung, triggerbasierter Erfassung von Änderungen, Push/Pull-Replikation und unabhängiger Verwaltung der einzelnen Replikationsziele bietet eine robuste Grundlage für hochverfügbare und verteilte Firebird-Systeme.

Für Unternehmen, die eine Firebird-Migration, ein Hochverfügbarkeitsprojekt, eine verteilte Datenbankarchitektur oder eine Synchronisierung nahezu in Echtzeit planen, ist eine technische Analyse der bestehenden Datenbankumgebung der erste Schritt.

Auf Grundlage der Datenbank-Metadaten und aktueller Datenbankstatistiken können anschließend eine realistische Implementierungsplanung, eine geeignete Replikationsarchitektur und ein projektspezifisches Angebot erstellt werden.

IBExpertFunctionLibrary Documentation

(German-language version below)

What is IBExpertFunctionLibrary?

IBExpertFunctionLibrary is a collection of Firebird database functions developed by IBExpert as a modern replacement for older UDF libraries (FreeAdhocUDF and rFunc).

Traditional Firebird UDFs are external binary libraries, usually written in languages such as C/C++ or Pascal. They were commonly used with Firebird 2.x to add functionality that was not available directly in SQL.

The problem is that binary UDFs are platform-dependent and can also affect server stability. A faulty UDF can potentially crash the Firebird server process. For this reason, Firebird has gradually moved away from traditional UDFs.

Why was IBExpertFunctionLibrary created?

Starting with Firebird 3, Firebird recommends newer mechanisms such as:

Stored Functions
UDRs - User Defined Routines

instead of traditional binary UDFs.

From Firebird 4 onward, traditional UDF support is disabled by default in firebird.conf.

This creates a migration problem for older applications that contain SQL such as:

SELECT some_old_udf(field1)
FROM customer;

or:

SELECT rFuncFunction(...)
FROM orders;

Rewriting a large application and all its database code can be expensive.

IBExpertFunctionLibrary was created primarily to provide replacements for these legacy functions while allowing applications to run on modern Firebird versions.

Main use case

The most important scenario is:

Old Firebird 2.x application -> uses FreeAdhocUDF / rFunc -> database upgraded to Firebird 3 / 4 / 5 -> IBExpertFunctionLibrary provides compatible replacements

This can significantly reduce the amount of application SQL that must be changed during a Firebird migration.

How does it differ from an old UDF library?

With an old UDF, the database declaration typically references an external binary library:

DECLARE EXTERNAL FUNCTION MY_FUNCTION
VARCHAR(255)
RETURNS VARCHAR(255)
ENTRY_POINT 'MyFunction'
MODULE_NAME 'myudf';

That means Firebird has to load something such as:

myudf.dll

on Windows or:

myudf.so

on Linux.

The binary also needs to match the operating system and architecture. A Windows 64-bit UDF cannot simply be copied to a Linux Firebird server.

IBExpertFunctionLibrary instead targets the newer Firebird function mechanisms, avoiding reliance on the old UDF architecture where possible.

Compatibility

The current library covers almost all functions available in FreeAdhocUDF and rFunc.

Some legacy functions cannot reasonably be reproduced using modern Firebird functionality. In those cases, IBExpert may provide a non-functional prototype so that existing SQL does not immediately fail because the function name is missing.

This distinction is important when migrating an application:

Function exists ≠ Function necessarily produces the old result

Functions used by business-critical SQL should therefore be tested after migration.

Typical migration workflow

A practical migration would normally look like this:

1. Identify existing external functions

Inspect the old database for UDF declarations and determine which libraries they belong to.

Typical examples may come from:

FreeAdhocUDF, rFunc and custom application UDFs.

2. Determine where the functions are used

Search:

stored procedures, triggers, views, stored functions, application SQL.

3. Compare them with IBExpertFunctionLibrary

Determine whether an equivalent implementation exists.

4. Install/create the replacement functions

The exact deployment scripts are supplied with the licensed IBExpertFunctionLibrary source/package rather than being documented on the public product page.

5. Test the database

Particularly check functions involving:

Strings, dates, numeric conversion, NULL handling, character sets, BLOBs.

6. Remove the old binary UDF dependency

Once all calls have been migrated and verified, the old DLL/SO library should no longer be necessary.

Stored Functions vs UDFs

A Firebird stored function behaves much more like normal SQL database code:

CREATE FUNCTION CALCULATE_VALUE (
A INTEGER,
B INTEGER
)
RETURNS INTEGER
AS
BEGIN
RETURN A + B;
END

It can then be called directly:

SELECT CALCULATE_VALUE(10, 20)
FROM RDB$DATABASE;

Result: 30

This approach has several advantages over traditional UDFs:

No external DLL/SO
No architecture-specific binary
Much easier deployment
Better server isolation
Database code can be backed up with database metadata
Firebird introduced stored functions in Firebird 3.

UDR vs Stored Function

The two modern approaches serve slightly different purposes.

Feature	Stored Function	UDR
Written in SQL/PSQL	Yes	Usually no
External compiled code	No	Usually yes
Suitable for simple logic	Excellent	Yes
Complex external processing	Limited	Excellent
Deployment complexity	Low	Higher
Replacement for many classic UDFs	Yes	Yes

For functions that can be implemented using Firebird SQL/PSQL, a stored function is usually the simpler option.

A UDR is useful when functionality genuinely requires external compiled code.

Important migration consideration

Functions from different historical libraries are not always parameter-compatible, even if they perform similar operations.

For example, a legacy function equivalent to Firebird's:

SUBSTRING(...)

may use a different argument order or indexing convention.

Therefore, migration should not simply be:

old function name -> new function name

without checking parameters and return values.

A safer approach is:

Old function -> Check parameter types -> Check NULL behaviour -> Check result type ->
Compare sample results -> Replace

In short

IBExpertFunctionLibrary is most useful when you have:

an older Firebird application + FreeAdhocUDF / rFunc / legacy UDF dependencies + a planned migration to Firebird 3, 4 or 5.

Instead of continuing to depend on old binary UDF libraries, it provides a migration path toward modern Firebird functions.

For a new Firebird 5 application, however, it generally makes more sense to use Firebird built-in functions, stored functions and UDRs directly, rather than introduce compatibility functions unless they are actually needed.

IBExpertFunctionLibrary Dokumentation

Was ist die IBExpertFunctionLibrary?

IBExpertFunctionLibrary ist eine Sammlung von Firebird-Datenbankfunktionen, die von IBExpert als moderner Ersatz für ältere UDF-Bibliotheken (FreeAdhocUDF und rFunc) entwickelt wurde.

Herkömmliche Firebird-UDFs sind externe Binärbibliotheken, die in der Regel in Sprachen wie C/C++ oder Pascal geschrieben sind. Sie wurden häufig in Verbindung mit Firebird 2.x verwendet, um Funktionen hinzuzufügen, die in SQL nicht direkt verfügbar waren.

Das Problem besteht darin, dass binäre UDFs plattformabhängig sind und zudem die Stabilität des Servers beeinträchtigen können. Eine fehlerhafte UDF kann unter Umständen zum Absturz des Firebird-Serverprozesses führen. Aus diesem Grund hat sich Firebird nach und nach von herkömmlichen UDFs verabschiedet.

Warum wurde die IBExpertFunctionLibrary entwickelt?

Ab Firebird 3 empfiehlt Firebird neuere Mechanismen wie:

Gespeicherte Funktionen
UDRs – benutzerdefinierte Routinen

anstelle herkömmlicher binärer UDFs.

Ab Firebird 4 ist die Unterstützung für herkömmliche UDFs in der Datei firebird.conf standardmäßig deaktiviert.

Dies führt zu einem Migrationsproblem für ältere Anwendungen, die SQL-Anweisungen wie die folgenden enthalten:

SELECT some_old_udf(field1)
FROM customer;

oder:

SELECT rFuncFunction(...)
FROM orders;

Das Neuprogrammieren einer großen Anwendung und ihres gesamten Datenbankcodes kann kostspielig sein.

Die IBExpertFunctionLibrary wurde in erster Linie entwickelt, um Ersatz für diese Legacy-Funktionen zu bieten und gleichzeitig die Ausführung von Anwendungen auf modernen Firebird-Versionen zu ermöglichen.

Haupteinsatzbereich

Das wichtigste Szenario ist:

Alte Firebird 2.x-Anwendung -> verwendet FreeAdhocUDF / rFunc -> Datenbank auf Firebird 3 / 4 / 5 aktualisiert -> IBExpertFunctionLibrary bietet kompatible Ersatzfunktionen.

Dadurch lässt sich der Umfang der SQL-Anweisungen in der Anwendung, die bei einer Firebird-Migration geändert werden müssen, erheblich reduzieren.

Wie unterscheidet sie sich von einer alten UDF-Bibliothek?

Bei einer alten UDF verweist die Datenbankdeklaration in der Regel auf eine externe Binärbibliothek:

DECLARE EXTERNAL FUNCTION MY_FUNCTION
VARCHAR(255)
RETURNS VARCHAR(255)
ENTRY_POINT 'MyFunction'
MODULE_NAME 'myudf';

Das bedeutet, dass Firebird eine Datei wie beispielsweise

myudf.dll

unter Windows oder

myudf.so

unter Linux laden muss.

Die Binärdatei muss zudem mit dem Betriebssystem und der Architektur übereinstimmen. Eine 64-Bit-UDF für Windows kann nicht einfach auf einen Linux-Firebird-Server kopiert werden.

Die IBExpertFunctionLibrary zielt stattdessen auf die neueren Firebird-Funktionsmechanismen ab und vermeidet, sofern möglich, die Abhängigkeit von der alten UDF-Architektur.

Kompatibilität

Die aktuelle Bibliothek deckt nahezu alle in FreeAdhocUDF und rFunc verfügbaren Funktionen ab.

Einige ältere Funktionen lassen sich mit den modernen Funktionen von Firebird nicht sinnvoll nachbilden. In solchen Fällen stellt IBExpert möglicherweise einen nicht funktionsfähigen Prototyp bereit, damit bestehende SQL-Anweisungen nicht sofort fehlschlagen, weil der Funktionsname fehlt.

Diese Unterscheidung ist bei der Migration einer Anwendung wichtig:

Die Funktion existiert ≠ Die Funktion liefert zwangsläufig das alte Ergebnis

Funktionen, die in geschäftskritischen SQL-Anweisungen verwendet werden, sollten daher nach der Migration getestet werden.

Typischer Migrationsablauf

Eine praktische Migration würde normalerweise wie folgt ablaufen:

1. Vorhandene externe Funktionen identifizieren

Überprüfen Sie die alte Datenbank auf UDF-Deklarationen und ermitteln Sie, zu welchen Bibliotheken diese gehören.

Typische Beispiele hierfür sind:

FreeAdhocUDF, rFunc und benutzerdefinierte Anwendungs-UDFs.

2. Ermitteln Sie, wo die Funktionen verwendet werden

Suche:

Stored Procedures, Trigger, Views, Stored Functions, Anwendungs-SQL.

3. Vergleichen Sie diese mit der IBExpertFunctionLibrary

Stellen Sie fest, ob eine entsprechende Implementierung vorhanden ist.

4. Die Ersatzfunktionen installieren/erstellen

Die genauen Deployment-Skripte sind im lizenzierten IBExpertFunctionLibrary-Quellcode bzw. -Paket enthalten und nicht auf der öffentlichen Produktseite dokumentiert.

5. Testen Sie die Datenbank

Überprüfen Sie insbesondere Funktionen in folgenden Bereichen:

Zeichenketten, Datumsangaben, numerische Konvertierung, Umgang mit NULL-Werten, Zeichensätze, BLOBs.

6. Entfernen Sie die alte binäre UDF-Abhängigkeit

Sobald alle Aufrufe migriert und überprüft wurden, sollte die alte DLL-/SO-Bibliothek nicht mehr benötigt werden.

Gespeicherte Funktionen vs. UDFs

Eine gespeicherte Firebird-Funktion verhält sich viel eher wie normaler SQL-Datenbankcode:

CREATE FUNCTION CALCULATE_VALUE (
A INTEGER,
B INTEGER
)
RETURNS INTEGER
AS
BEGIN
RETURN A + B;
END

Es kann dann direkt aufgerufen werden:

SELECT CALCULATE_VALUE(10, 20)
FROM RDB$DATABASE;

Ergebnis: 30

Dieser Ansatz bietet gegenüber herkömmlichen UDFs mehrere Vorteile:

Keine externen DLLs/SO-Dateien
Keine architekturabhängigen Binärdateien
Deutlich einfachere Bereitstellung
Bessere Serverisolierung
Der Datenbankcode kann zusammen mit den Datenbank-Metadaten gesichert werden
Firebird hat in Firebird 3 gespeicherte Funktionen eingeführt.

UDR vs. Stored Function

Die beiden modernen Ansätze dienen leicht unterschiedlichen Zwecken.

Merkmal	Stored Function	UDR
In SQL/PSQL geschrieben	Ja	In der Regel nein
Externer kompilierter Code	Nein	In der Regel ja
Geeignet für einfache Logik	Hervorragend	Ja
Komplexe externe Verarbeitung	Eingeschränkt	Hervorragend
Komplexität bei der Bereitstellung	Gering	Höher
Ersatz für viele klassische UDFs	Ja	Ja

Bei Funktionen, die mit Firebird SQL/PSQL implementiert werden können, ist eine gespeicherte Funktion in der Regel die einfachere Option.

Eine UDR ist dann sinnvoll, wenn die Funktionalität tatsächlich externen kompilierten Code erfordert.

Wichtige Migrationshinweise

Funktionen aus verschiedenen älteren Bibliotheken sind nicht immer parameterkompatibel, auch wenn sie ähnliche Operationen ausführen.

Beispielsweise kann eine ältere Funktion, die der Firebird-Funktion

SUBSTRING(...)

entspricht, eine andere Argumentreihenfolge oder Indizierungskonvention verwenden.

Daher sollte die Migration nicht einfach wie folgt erfolgen:

alter Funktionsname -> neuer Funktionsname

ohne die Parameter und Rückgabewerte zu überprüfen.

Eine sichere Vorgehensweise ist:

Alte Funktion -> Parametertypen prüfen -> Verhalten bei NULL prüfen -> Ergebnistyp prüfen ->
Beispielergebnisse vergleichen -> Ersetzen

Zusammenfassung

IBExpertFunctionLibrary ist in folgende Situationen besonders nützlich:

eine ältere Firebird-Anwendung + Abhängigkeiten von FreeAdhocUDF, rFunc oder älteren UDFs + eine geplante Migration auf Firebird 3, 4 oder 5.

Anstatt weiterhin auf alte binäre UDF-Bibliotheken angewiesen zu sein, bietet sie einen Migrationspfad hin zu modernen Firebird-Funktionen.

Bei einer neuen Firebird-5-Anwendung ist es jedoch in der Regel sinnvoller, die integrierten Funktionen, Stored Functions und UDRs von Firebird direkt zu verwenden, anstatt Kompatibilitätsfunktionen einzuführen, sofern diese nicht tatsächlich benötigt werden.

IBExpert Personal Edition won't start

Make sure you always use the most up-to-date IBExpert Personal Edition. The latest IBExpert software version is available from the IBExpert Download Center.

Check whether you have requested too many free activations (see Error: too many Personal Edition registrations).

If the IBExpert Personal Edition still does not start, check your inbox for messages from our IBExpert server with advice on possible causes or problems.

Error: too many registrations for the Personal Edition

After clicking “Get code” I received the following error message: Error: too many registrations for personal edition from your network…

This is not an error. If you check the IBExpert Personal Edition conditions, you will see that you have exceeded the number of legal downloads allowed for this free edition: free IBExpert Personal Edition.

Due to the vast amounts of downloads the free IBExpert Personal Edition registration procedure is fully automated. We can therefore provide neither support nor service for this software edition. Please do not write to us, or request manual activations.

By activating the IBExpert Personal Edition registration you are also agreeing to the terms stated in the Activation Code email:

1. The Personal Edition is certainly not intended for commercial use on multiple computers in a company, nor to be passed on or sold to others.

2. The Personal Edition may not be activated for other users.

3. Use of the IBExpert Personal Edition is only allowed by the person who has conducted the download from his/her account in the IBExpert Download Center.

4. A developer may use the Personal Edition commercially at his employer's (according to the terms in 3.).

Any use by any other person or any form of distribution is strictly prohibited without prior written permission and will be prosecuted.

You will need to agree to these usage terms before you enter the unlock code.

If you need or intend to use IBExpert for any other purpose than personal use, you must purchase a full IBExpert Developer Studio Edition incl. 12 month software subscription. If you only use IBExpert occasionally (for example, for customer support), the IBExpert Day Edition may be suitable for your needs.

You can view all IBExpert software and fees on our website: IBExpert products, services & prices.

IBEScript – Firebird-Skripte automatisiert ausführen

Mit IBEScript lassen sich Firebird-Skripte komfortabel über die Windows-Kommandozeile automatisiert ausführen. Das eigenständige Kommandozeilen-Tool eignet sich ideal für geplante Aufgaben, Installationsroutinen, Batch-Dateien und CI/CD-Prozesse – ganz ohne grafische Benutzeroberfläche.

Die Abbildung zeigt die aktuelle Hilfeausgabe der 64-Bit-Windows-Version von IBEScript 2026.07.29.

Bereits der Aufruf von ibescr64.exe zeigt alle verfügbaren Kommandozeilenoptionen, darunter Funktionen für Protokollierung, Fehlerbehandlung, Verbindungen und Skriptverschlüsselung.

Automatisierung von Datenbankprozessen

IBEScript befindet sich im IBExpert-Installationsverzeichnis und kann direkt über die Kommandozeile gestartet werden. Dadurch lassen sich wiederkehrende Aufgaben zuverlässig automatisieren, beispielsweise:

Erstellung und Einrichtung von Firebird-Datenbanken
Ausführung von Update- und Wartungsskripten
Datenmigrationen
automatisierte Reports und Exporte
Integration in Installations- und Deployment-Prozesse

Die grundlegende Syntax:

IBEScript script_filename [options]

Beispiel:

IBEScript C:\Scripts\CreateDB.sql

Umfangreiche Steuerungsmöglichkeiten

IBEScript bietet zahlreiche Optionen zur Kontrolle der Skriptausführung:

ausführliche Ablaufprotokolle und Fehlerausgaben
Speicherung von Logdateien mit Zeitstempel
Fortschrittsanzeige bei umfangreichen Skripten
flexible Übergabe von Verbindungsparametern
Verschlüsselung und Schutz von Skriptdateien

Leistungsfähige IBEBlock-Unterstützung

Durch die integrierte IBEBlock-Technologie können auch komplexe Datenbankoperationen automatisiert durchgeführt werden.

Mögliche Einsatzbereiche:

Übertragung von Daten zwischen mehreren Firebird- oder InterBase®-Datenbanken
Zugriff auf externe ODBC-Datenquellen wie Microsoft Access®, Oracle® oder IBM DB2®
Vergleich und Synchronisation von Datenbankstrukturen über ibec_CompareMetadata
automatisierte Erstellung von Reports aus dem IBExpert Report Manager

Zusätzlich unterstützt IBEScript den Import und Export von Dateien in Datenbankfeldern, beispielsweise für BLOB-Daten, sowie die Verwendung von Umgebungsvariablen für flexible Installationen.

Warum sich IBEScript lohnt

IBEScript erweitert IBExpert um eine leistungsfähige Kommandozeilen-Schnittstelle für professionelle Datenbankautomatisierung.

Von einfachen SQL-Ausführungen bis hin zu komplexen Migrationen, Datenbankvergleichen und automatisierten Reports bietet IBEScript alle Werkzeuge, um Firebird-Prozesse effizient und zuverlässig zu steuern.

IBEScript ist damit eine ideale Ergänzung für Entwickler, Administratoren und Unternehmen, die wiederkehrende Datenbankaufgaben automatisieren möchten.

Hinweis: IBEScript ist Bestandteil der IBExpert Developer Studio Edition, der IBExpert Server Tools sowie der IBExpert Company Year Editions und steht in dieser Form nicht in der kostenlosen IBExpert Personal Edition zur Verfügung.

Newsletter D 05a/2026

Firebird Server Health Check & Backup Monitoring – auch für eigene Hardware

Sie nutzen Firebird auf eigener oder bereits vorhandener Server-Hardware?

Mit unserem 3-Jahres-Servicepaket prüfen und überwachen wir die wichtigsten Grundlagen für einen stabilen Betrieb.

Zum Pauschalpreis von 1.750 € für 3 Jahre führen wir eine initiale Remote-Analyse durch, prüfen Backup- und Restore-Automatisierung, bewerten die Serverleistung per Benchmark und kontrollieren vorhandene Firebird-Konfigurationen.

Zusätzlich erfolgen vierteljährliche Basischecks per Remote-Sitzung. Sie laden uns dazu nach vorheriger E-Mail mit einer Remote-Software Ihrer Wahl ein. Über ein automatisiertes IBEBlock-Script werden regelmäßige Backups zentral protokolliert und überwacht, um Fehler frühzeitig erkennen zu können. ... weiterlesen