(German-language version below)
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.
Starting with Firebird 3, Firebird recommends newer mechanisms such as:
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.
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.
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.
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.
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.
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:
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.
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
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 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.
Ab Firebird 3 empfiehlt Firebird neuere Mechanismen wie:
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.
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.
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.
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.
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.
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:
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.
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
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.