(German-language version below)

From the initial idea to deployment

The networked world today requires a powerful and flexible integration of mobile data acquisition devices in most commercial areas. While the apps in the Apple world hardly allow any really long-term application development without Xcode, in the Android world it is also difficult to be competitive without Android Studio. Alternative concepts such as the FMX implementation in more recent Delphi versions as well as Xamarin or similar frameworks promise multi-platform capability, the reality however is somewhat different. The first rollout of a native app requires a lot of know-how, and even seemingly trivial problems can cause long waiting times until the full version can be used by the customer.

If you are a software manufacturer and want to expand your ERP or business software by offering a flexible module for mobile devices, you will find several man-months or even man-years of development work, which can hardly be refinanced. Your customers expect such a feature on their own smartphones; however they are not willing to pay additional costs.

A decision to use only Android as a platform will not be acceptable for customers with Apple devices, so that the iOS platform for Apple also needs to be implemented. The development costs thus double and even a mundane task, such as mobile time tracking for field service technicians must also be implemented on these two platforms, in addition to the back-office solution for the office employees or on laptops, for which the source code cannot be used across multiple platforms.

Let’s stay with the example of mobile time tracking and consider alternative methods. Certainly, there are places where mobile phone reception is not always available or poor, but generally it can be assumes in most areas of Western Europe that a sufficiently good connection can be ensured. This is certainly a different matter in the Australian outback, but in such a case we would use a fully-fledged replicated database on a laptop, to enable access to even large amounts of data at any time.

In our 2-day training course Bootcamp database web applications using Firebird, you will learn all knowledge necessary to visualize data from a Firebird database via an Apache web server on Windows or Linux with minimal PHP knowledge.

A registration of the mobile device can be permanently assigned by URL or an individual view of the assigned data is displayed interactively using the Username and Password. In this way the sample application "Mobile Time Tracking" can display instructions for selection directly assigned to the user of the mobile device, minimizing errors such as booking time to the wrong jobs.

Simple control elements, known in the Delphi world as TLabel, TEdit, TMemo, TCombobox, TButton, TListbox, etc., are recorded on the website by the logic instructions, which are implemented in Firebird stored procedures, and filled with data from the database. The user can now enter numbers or strings depending upon the task, or simply trigger a Start- or Stop-booking with a simple click.

The resulting data is written back into the Firebird database by the Apache/PHP script. These can create messages at any time via triggers and events in the back office, and can alert the person responsible to new mobile data, or can be fully automated in collective bills.

You have no PHP experience? No problem, the PHP script used contains only around 30 lines and these will only altered in very few places during the whole training.

Do you lack basic knowledge of HTML controls? During the course, we will provide you with all the necessary basic knowledge, enabling you to extend this knowledge yourself at any time in the future.

You have never set up an Apache web server on Windows or Linux with PHP, or set up PHP access to Firebird? This is also part of our training. We’ll set up a virtual Windows server together. This server with the exact same configuration is offered by Hosteurope for EUR 9.90 a month.

How do you get the data rapidly from the local database to the Firebird database on the virtual server, without having to store all data there, and to make it publicly available in case of a faulty configuration? We explain the most important security aspects of such a Firebird configuration and show how to exchange data between the customer server and the server on the VM in near real-time using the push-pull principle.

Does this work even if the data is not stored locally in Firebird databases? Yes, we use IBEScript to show you basic IBEBlock scripts, which allow you to connect to any ODBC-compliant database to write the local data into your Firebird database vice versa.

How can the server-side application be used to send e-mails and generate PDFs, for example, to automatically generate order confirmations around the clock? We will show you how it is possible to use the IBEBlock Script on the server side. In addition to Windows for IBEscript.exe, we can also use Linux with Wine. 

Bootcamp Datenbankwebapplikationen mit Firebird

Von der Idee zur Umsetzung 

Die vernetzte Welt erfordert mittlerweile für nahezu sämtliche Geschäftsbereiche eine leistungsfähige und flexible Integration von mobilen Datenerfassungsgeräten. Während jedoch die Apps in der Applewelt kaum ohne Xcode wirklich langfristige Applikationsentwicklungen ermöglichen, ist man in der Android Welt ohne Android Studio ebenfalls kaum wettbewerbsfähig. Alternative Konzepte, wie die FMX Implementation in neueren Delphi Version ebenso wie Xamarin oder ähnliche Frameworks versprechen Multiplattformfähigkeit, aber die Realität sieht anders aus. Das erste Rollout einer nativen App bedarf einer Unmenge an Know-how und selbst scheinbar banale Probleme sorgen für lange Wartezeiten bis zur Nutzung der vollständigen Version durch den Kunden.

Wenn Sie als Softwarehersteller nun Ihre ERP- oder Branchensoftware um ein flexibles Modul für Mobilegeräte erweitern möchten, kommen auch bei einfachen Anwendungen mehrere Mannmonate oder sogar Mannjahre Entwicklungsarbeit zusammen, die sich kaum refinanzieren lassen. Ihre Kunden erwarten zwar eine derartige Funktion auf dem eigenen Smartphone, sind aber nicht bereit, dafür zusätzliche Kosten zu tragen. Eine Entscheidung für Android als Plattform wird von den Kunden mit Apple Geräten nicht akzeptiert und die iOS Plattform für Apple muss zusätzlich umgesetzt werden. Der Entwicklungsaufwand verdoppelt sich und selbst eine banale Aufgabe, wie zum Beispiel eine mobile Arbeitszeiterfassung für den Außendiensttechniker muss neben der Back Office Lösung für Mitarbeiter im Büro oder auf Laptops zusätzlich noch in 2 anderen Plattformen implementiert werden, bei denen der Quellcode auch nicht plattformübergreifend eingesetzt werden kann.

Bleiben wir beim Beispiel einer mobilen Arbeitszeiterfassung und denken wir über alternative Verfahren nach. Sicherlich gibt es Orte, an denen eine mobile Funkverbindung per Handy nicht immer gewährleistet ist, aber generell kann man in den meisten relevanten Gebieten Westeuropas davon ausgehen, dass eine ausreichend gute Verbindung gewährleistet ist. Im australischen Outback ist das sicherlich anders, aber hier würden wir eine vollwertige replizierte Datenbank auf einem Laptop einsetzen, um auch sehr große Datenmengen jederzeit vor Ort im Zugriff zu haben.

Im Rahmen unseres Bootcamps "Datenbankwebapplikationen mit Firebird" zeigen wir Ihnen innerhalb von 2 Tagen das gesamte Know-how, um Daten aus einer Firebird Datenbank über einen Apache Webserver auf Windows- oder Linux Basis mit minimalen PHP Kenntnissen zu visualisieren.

Eine Anmeldung des Mobilgeräts kann per URL fest vergeben werden oder die individuelle Sicht auf die zugeordneten Daten erfolgt interaktiv per Username und Password. So kann die Beispielanwendung "Mobile Zeiterfassung" direkt dem Benutzer des Mobilgeräts zugeordnete Aufträge zur Auswahl anzeigen und Fehleingaben wie Buchungen auf falsche Aufträge minimieren.

Einfache Kontrollelemente, in der Delphi Welt als TLabel, TEdit, TMemo, TCombobox, TButton, TListbox, etc. bekannt, werden durch die in Firebird Stored Procedures implementierten Logikanweisungen entsprechend der Anforderungen in der Webseite aufgenommen und durch Daten aus der Datenbank gefüllt. Der Anwender kann entsprechend der Aufgabe nun Zahlen oder Zeichenfolgen erfassen oder einfach eine Start oder Stop Buchung durch einen einfachen Klick auslösen.

Die Daten, die sich daraus ergeben, werden vom Apache/PHP Script wieder zurück in die Firebird Datenbank geschrieben. Diese können jederzeit via Trigger und Events im Backoffice Nachrichten erstellen und den Sachbearbeiter auf neue, mobil erfasste Daten hinweisen oder vollautomatisiert in Sammelrechnungen übernommen werden.

Sie haben keine PHP Erfahrung? Kein Problem, das benutzte PHP Script hat nur ca. 30 Zeilen und wird während der gesamten Schulung nur an ganz wenigen Stellen geändert.

Ihnen fehlen die Basiskenntnisse für die HTML Kontrollelemente? Wir vermitteln Ihnen im Rahmen des Bootcamps alle erforderlichen Basiskenntnisse, so dass Sie, sofern erforderlich, jederzeit durch eine spätere Recherche im Internet diese Kenntnisse erweitern können.

Sie haben noch nie einen Apache Webserver auf Windows oder Linux mit PHP oder den Zugriff von PHP auf Firebird eingerichtet? Auch dieser Punkt ist ein Bestandteil unseres Bootcamps. Wir richten gemeinsam einen virtuellen Windows Server ein. Dieser Server kann bei Hosteurope in genau dieser Konfiguration für 9,90 im Monat gemietet werden.

Wie bekommt man zeitnah die Daten von der lokalen Datenbank auf die Firebird Datenbank auf dem virtuellen Server, ohne sämtliche Daten dort zu lagern und im Fall einer fehlerhaften Konfiguration öffentlich verfügbar zu haben? Wir erklären die wichtigsten Sicherheitsaspekte einer solchen Firebird Konfiguration und zeigen, wie man im Push/Pull Prinzip Daten in nahezu Echtzeit zwischen einem Kundenserver und dem Server auf der VM austauscht.

Funktioniert das auch, wenn meine Daten lokal gar nicht in Firebird Datenbanken gespeichert werden? Ja, wir zeigen mit IBEScript grundlegende IBEBlock Scripte, mit denen Sie sich mit jeder ODBC-fähigen Datenbank verbinden können um die Daten von dort in die Firebird Datenbank oder aus der Firebird Datenbank zurück in Ihre Plattform zu schreiben.

Wie kann ich mit der Anwendung serverseitig E-Mails versenden und PDFs erzeugen, um zum Beispiel Auftragsbestätigungen automatisch rund um die Uhr zu erzeugen? Wir zeigen wir Ihnen, wie es mit Hilfe der IBEBlock Script serverseitig machbar ist. Wir setzen für IBEscript.exe neben Windows auch Linux mit Wine ein. 

The Cloud and Firebird: The physical fundamentals of failure or why it works really well when you do it right!

Holger Klemt, June 2022

Read more

(German-language version below)

The IBExpert Day Edition contains all the features of the IBExpert IDE, e.g. debugger, performance analysis and much more.

IBExpert can be used on registered computers for 24 hours following activation. After the 24 hour period IBExpert will no longer start on this computer, but can be activated again.

Use IBExpert wherever you or your employees work

In the home office
For customer support
On customer computers, e.g. as a supplement to the Company Year Edition

The automatic termination after 24 hours minimizes the risk of running an unlicensed product on customer machines.

Or for other tasks

Benchmark tests
Training purposes
Tests

Also as a cost-effective introduction

For your trainees and interns
And of course also for testing for new customers

And also at hand in case of emergency

For short-term use on another computer, e.g. if you cannot generate a removal code when moving to another computer, or your computer is broken.

IBExpert Day Edition Packages

There are a number of IBExpert Day Edition Packages. Please refer to our IBExpert products, services & prices page for details.

Please register in the IBExpert Download Center for this product with a valid e-mail address. If possible, use a use a company address such as support@companyx.com, ibexpertday@computerenterprise.com or similar.

The software activations are made available on your user account in the IBExpert Download Center for a period of 12 months from the date of purchase.

Afterwards any unused activations will automatically expire. To prevent this, you can purchase a new IBExpert Day Edition package before the expiry date, so that unused activations are credited for a further 12 months.

The IBExpert Day Edition is the ideal supplement to all IBExpert full versions, ready for use on all computers at any time.

The IBExpert Day Edition can also be run on Linux/Wine.

You can download the latest IBExpert IDE setup file from the IBExpert Download Center and distribute it with your software product. If you wish to work with IBExpert on your customer servers, activate one of your Day Editions with your e-mail address/password combination to start IBExpert.

IBExpert Day Edition

Die IBExpert Day Edition enthält alle Funktionen der IBExpert IDE, z.B. Debugger, Performanceanalyse u.v.m.

IBExpert kann nach der Freischaltung 24 Stunden auf dem Computer benutzt werden. Nach Ablauf von 24 Stunden wird IBExpert auf diesem Computer nicht mehr starten, kann aber erneut wieder freigeschaltet werden.

Benutzen Sie IBExpert überall dort, wo Sie oder Ihre Mitarbeiter arbeiten:

Im Office
Im Homeoffice
Im Kundensupport
Auf Kundenrechnern, z.B. als Ergänzung zur Company Year Edition

Durch das automatische Beenden nach 24 Stunden minimiert sich das Risiko, ein nicht lizenziertes Produkt auf Kundenrechnern zu betreiben

Oder für andere Aufgaben

Für Benchmarktests
Für Schulungszwecke
Für Tests

Auch als günstiger Einstieg

Für Ihre Auszubildenden und Praktikanten
Und natürlich auch zum Testen für Neukunden

Und auch im Notfall zur Hand

Für den kurzfristigen Einsatz auf einem anderen Computer, z.B., wenn Sie keinen Removal Code beim Umzug auf einen anderen Computer erzeugen können, oder Ihr Computer defekt ist.

IBExpert Day Edition Pakete

Es gibt eine Auswahl an IBExpert Day Edition Paketen. Bitte entnehmen Sie die Details unserer IBExpert Produkte, Dienstleistungen & Preise-Seite.

Bitte registrieren Sie sich im IBExpert Download Center für dieses Produkt mit einer gültigen E-Mail-Adresse. Verwenden Sie nach Möglichkeit eine Firmenadresse wie z.B.support@companyx.com, ibexpertday@computerenterprise.de oder ähnliches.

Die Freischaltungen erfolgen auf Ihrem User Account im IBExpert Download Center für einen Zeitraum von 12 Monaten ab Kaufdatum.

Nicht angeforderten Aktivierungen verfallen danach automatisch. Um dieses zu verhindern, können Sie rechtzeitig vor Ablauf ein neues IBExpert Day Edition Paket erwerben, damit werden nicht angeforderte Aktivierungen für die nächsten 12 Monate gutgeschrieben.

Die IBExpert Day Edition ist die ideale Ergänzung zu allen IBExpert Vollversionen, jederzeit auf allen Computern einsatzbereit.

Die IBExpert Day Edition ist auch mit Linux/Wine lauffähig.

Sie können die aktuelle IBExpert IDE-Setup-Datei im IBExpert Download Center herunterladen und mit Ihrem Software-Produkt verteilen. Wenn Sie mit IBExpert auf Ihren Kundenservern arbeiten möchten, aktivieren Sie eine Ihrer Day Editions mit Ihrer E-Mail-Adresse/Passwort Kombination, um IBExpert zu starten.

(German-language version below)

A user-defined function (UDF) is utilized to perform tasks that Firebird can't. It is an external database function written entirely in another language, such as C++ or Pascal, to perform data manipulation tasks that not directly supported by Firebird/InterBase.

As a lot of Firebird-based software developers know, these functions help you to extend the SQL language as required. But on the downside, the binary implementation requires a compiler on the platform where you want to use the Firebird server. A UDF library available for Win64 can neither be used on Win32 nor on Linux.

Up to Firebird 2.5 the UDF was an extremely powerful implementation, but unfortunately also a critical point of failure. If any of your binary code was not as stable as it should be, especially in multi-user environments, it could crash the Firebird server completely. All connected users would be disconnected, and even though the database file itself should not contain a binary error after this happened, any user application had to be restarted. This might not have been such a big problem with the Firebird Classic version, but today, using a binary UDF is no longer recommended.

This was the reason for the Firebird Project to introduce the new and more stable UDR implementation. A UDR appears to be similar to a UDF, but it is loaded in a considerably more stable way on the server process, and an error in the implementation does not typically crash the server.

Since Firebird 3, it is recommended to use a UDR rather than a UDF and, starting with Firebird 4, the use of UDFs is deactivated by default in the firebird.conf file.

A further implementation for the functional extension of Firebird was also introduced with Firebird 3: stored functions. Similar to the UDR/UDF functions, a stored function can be implemented in the same way as it can be when using a stored procedure, but the concept of functions provides only one result based on the specified input params.

As you might know, there are widely-used UDF implementations, which are all too often completely outdated, such as the FreeAdhocUDF library, which has not been changed or improved during the last 12 years. Libraries like rFunc or FreeAdhocUDF often use very high know-how standards but, based on Firebird’s built-in functions such as substring, the parameter structure is not one-to-one compatible. If you want to use your existing Firebird 2.x-based software in a new non-UDF-based Firebird version 3 or 4, you will need a replacement.

For this reason we have developed a complete new set of functions called IBExpertFunctionLibrary.

IBExpertFunctionLibrary Enterprise Maintenance Subscription

Your company licenses the source code of the library as it is, but it is only permitted to use this with databases created by your company for internal or customer use.

This includes access to all new versions of the source code and up to 5 new functional implementations for 12 months.

These functional implementations are limited to the language features already possible in the Firebird language. External software required for the implementation, such as DLLs/SO or other libraries, are not covered by this, but on request, this can also be implemented.

Pricing

    IBExpertFunctionLibrary Enterprise Maintenance Subscription: EUR 1,020.00 

The current version 1.0 already basically covers almost all of the functions currently available in FreeAdhocUDF and rFunc. Some functions cannot be implemented or it no longer make any sense to implement them, but these will be available as empty non-functional prototypes, so that a call will not result in an error. 

IBExpertFunctionLibrary

Wie viele Firebird Softwareentwickler wissen, helfen Ihnen diese Funktionen dabei, die SQL-Sprache nach Bedarf zu erweitern. Der Nachteil ist jedoch, dass die binäre Implementierung einen Compiler auf der Plattform erfordert, auf der Sie den Firebird Server verwenden. Eine UDF-Bibliothek, die für Win64 verfügbar ist, kann weder unter Win32 noch unter Linux verwendet werden.

Bis zu Firebird 2.5 war die UDF eine extrem leistungsfähige Implementierung, aber leider auch ein kritischer Fehlerpunkt. Wenn einer Ihrer Binärcodes nicht so stabil war, wie er sein sollte, insbesondere in Mehrbenutzerumgebungen, konnte er den Firebird Server komplett zum Absturz bringen. Alle Client-Verbindungen wurden getrennt, und obwohl die Datenbankdatei selbst keinen Binärfehler enthalten sollte, musste jeder Client neu verbunden werden. Dies mag in der Firebird Classic Version kein so großes Problem gewesen sein, aber heute wird die Verwendung einer binären UDF nicht mehr empfohlen.

Dies war der Grund für das Firebird Projekt, die neue und stabilere UDR-Implementierung einzuführen. Eine UDR scheint einer UDF ähnlich zu sein, aber sie wird auf eine wesentlich stabilere Art und Weise in den Serverprozess geladen, und ein Fehler in der Implementierung führt normalerweise nicht zum Absturz des Servers.

Seit Firebird 3 wird empfohlen, eine UDR statt einer UDF zu verwenden und ab Firebird 4 ist die Verwendung von UDFs in der Datei firebird.conf standardmäßig deaktiviert.

Eine weitere Implementierung für die funktionale Erweiterung von Firebird wurde ebenfalls mit Firebird 3 eingeführt: Stored Functions. Ähnlich wie die UDR/UDF-Funktionen kann eine Stored Function auf die gleiche Weise wie eine Stored Procedure implementiert werden, aber das Konzept der Funktionen liefert nur ein Ergebnis basierend auf den angegebenen Eingabeparametern.

Wie Sie vielleicht wissen, gibt es weit verbreitete UDF-Implementierungen, die allzu oft völlig veraltet sind, wie z. B. die FreeAdhocUDF-Bibliothek, die in den letzten 12 Jahren weder geändert noch verbessert wurde. Bibliotheken wie rFunc oder FreeAdhocUDF verwenden oft sehr hohe Know-How-Standards, aber, basierend auf Firebirds eingebauten Funktionen wie z.B. substring, ist die Parameterstruktur nicht eins-zu-eins kompatibel. Wenn Sie Ihre bestehende Firebird 2.x-basierte Software in einer neuen, nicht UDF-basierten Firebird Version 3 oder 4 verwenden möchten, benötigen Sie einen Ersatz.

Aus diesem Grund haben wir einen komplett neuen Satz von Funktionen mit dem Namen IBExpertFunctionLibrary entwickelt.

IBExpertFunctionLibrary Enterprise Maintenance Subscription

Ihr Unternehmen lizenziert den Quellcode der Bibliothek, wie er ist, aber es ist nur erlaubt, diesen mit Datenbanken zu verwenden, die von Ihrem Unternehmen für den internen oder Kundengebrauch erstellt wurden.

Dies beinhaltet den Zugriff auf alle neuen Versionen des Quellcodes und bis zu 5 neue Funktionsimplementierungen für 12 Monate.

Diese funktionalen Implementierungen sind auf die Sprachfeatures beschränkt, die bereits in der Firebird-Sprache möglich sind. Externe Software, die für die Implementierung benötigt wird, wie z.B. DLLs/SO oder andere Bibliotheken, sind davon nicht abgedeckt, können aber auf Anfrage ebenfalls implementiert werden.

Preisgestaltung

IBExpertFunctionLibrary Enterprise Maintenance Subscription: EUR 1020,00

Die aktuelle Version 1.0 deckt im Grunde bereits fast alle Funktionen ab, die derzeit in FreeAdhocUDF und rFunc verfügbar sind. Einige Funktionen können nicht implementiert werden oder es macht keinen Sinn mehr, sie zu implementieren, aber diese werden als leere nicht-funktionale Prototypen verfügbar sein, so dass ein Aufruf nicht zu einem Fehler führt. 

(German-language version below)

The IBExpert Developer Studio Edition contains a IBExpert Developer Studio Full Version with a 12 month software subscription valid for 12 months from date of purchase.

IBExpert Developer Studio Edition

(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.

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.

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.