IBExpert Firebird 5 Bootcamp

(German-language version below)

---

IBExpert Firebird 5 Bootcamp

Das Firebird 5 Bootcamp wendet sich an Admins und Programmierer, die mindestens 2 Jahre aktiv mit Firebird arbeiten. Dabei konzentrieren wir uns auf den Umstieg auf Firebird 5 und die Optimierung der eigenen Datenbank-Umgebung. Es erwarten Sie interessante Themen rund um die Entwicklung mit Firebird, IBExpert, Lazarus und Delphi. Der Fokus liegt dabei konsequent auf dem praktischen Einsatz der vorgestellten Technologien und Methoden, die auch mit anderen Programmiersprachen umgesetzt werden können.

Profitieren Sie vom Wissen der IBExpert Datenbank Experten.

Themen im Überblick

Client Entwicklung

• Debuggen einer Delphi/Lazarus Datenbankanwendung mit dem integrierten Debugger
• Erstellen geeigneter Events für zusätzliche Protokolle auch ohne Debugger
• Netzwerkmonitoring der Datenbankkommunikation auf TCP/IP Paketebene
• IBExpert Database Monitoring
• Trace API einsetzen und auswerten
• Performancevergleich verschiedener Komponenten: TxxTable, TxxDataset, TxxQuery etc.
• Automatisch von Komponenten erzeugte SQLs erkennen und bewerten
• SQLs auf dem Server anhand von Quelltextergänzungen im Delphi/Lazarus Quellcode identifizieren
• Eigene Profiling Methoden automatisiert im Delphi/Lazarus Quellcode ergänzen
• Autocommit oder manuelles Commit?
• Mit Prepare oder ohne Prepare?
• SQLs mit oder ohne Parameter? Vor- und Nachteile!
• Befehle in Blocks zusammenfassen
• Einfache Webanwendungen erstellen

Server Entwicklung und administrative Aufgaben für Entwickler

• Basiswissen zur Arbeitsweise und Architektur des Firebird Servers
• Mangelhaftes Transaktionshandling erkennen und Auswirkungen bewerten
• Zuordnung langlaufender Transaktionen im Netzwerkbetrieb, Identifikation des Verursachers
• Techniken, um langlaufende Transaktionen serverseitig zu beenden
• Trigger Sequenzen analysieren und Ablauf protokollieren
• Geschwindigkeitsvorteile von Stored Procedures messen und bewerten
• Stored Procedures und Trigger mit IBExpert erstellen und debuggen
• Globale Datenbankanalyse: fehlende Primärschlüssel, doppelte, falsche und fehlende Indizes erkennen
• Berechnete Felder performant einsetzen und Anzeige über Berechtigungen steuern
• Datentypen und Tabellendefinitionen richtig einsetzen
• Execute Statement on External richtig einsetzen
• Basiswissen Replikation als Echtzeitbackup
• Datenbankmodell mit IBExpert visualisieren
• Datenbankmodell für eine Versionskontrolle in SVN o.ä. exportieren
• IBExpert für Versionierung von Stored Procedures und Trigger einrichten
• Automatisierter Metadatenabgleich zwischen Entwicklungsdatenbank und Produktionsdatenbank
• Automatisierter Datenabgleich zwischen mehreren Datenbanken per Script automatisieren

Administrative Aufgaben

• Datensicherung über Backup Werkzeuge im laufenden Betrieb einsetzen
• Laufzeit der Datensicherung optimieren
• Shadow als alternative High Speed Sicherungsmethode
• Hardwaregeschwindigkeit messen und vergleichen mit IBExpert Benchmark
• Serverseitiges Monitoring von Datenbankanwendungen
• Einrichtung eines 24/7 Monitoring Protokolls im Server
• Reports, automatisierter Import und Export csv, pdf etc
• Tipps und Tricks für optimale Hardware und Software für einen Firebird Server
• Was bringt die neue Mehrprozessorfähigkeit in Firebird 5.0 wirklich?
• Einsatzmöglichkeiten für Packages und Internal Functions
• Was muss man bei einer Umstellung auf Firebird 5.0 beachten?
• Benchmark Vergleich Firebird 3.0/Firebird 5.0
• IBExpert Tipps und Tricks für die tägliche Arbeit
• Warum SQL Befehle selber schreiben, wenn diese im IBExpert Assistent schnell und zuverlässig erzeugt werden können
• Softwaremodelle Developer Studio, Company Year Edition und Day Edition
• Firebird.conf optimieren  

IBExpert Firebird Bootcamps: Was unsere Kunden sagen

---

---

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.

Where Is Your Database Really Spending Its Time?

Have you ever investigated which SQL statements are unexpectedly slowing down your database?

With the IBExpert Full Version or Day Edition, you can see what is happening directly on the Firebird server. Simply right-click your registered database, select Start trace session, and enable tracing for your current connection. You can then follow statement preparation and execution, stored procedure calls, and trigger activity as they happen.

In the example shown, the seemingly unremarkable stored procedure P_USER_EINLOGGEN takes more than five seconds just to prepare the call, before execution even begins. A simple-looking SQL statement can hide a surprising amount of work.

These detailed trace results also give AI platforms the evidence they need to help you investigate performance problems and suggest targeted improvements. Without tools that reveal what the server actually does, even AI-assisted optimisation can quickly reach a dead end: the SQL text alone often does not explain where the time goes.

During our IBExpert Hotline Sessions, we can investigate these delays together, identify unexpected calls and dependency chains, explain why they occur, and work on ways to optimise your database.

Bring your trace results, and let’s find out where the time really goes.

'00-2' is not a valid integer value

This error appears if you are still using the old deprecated ibexpert.stg to store all your IBExpert settings. It indicates that IBExpert.stg is corrupted, cannot be repaired and user database should be used instead.

To solve this issue configure the IBExpert User Database.

If you have not specified a location yourself: by default, the user database file can always be found in the folder: \HK-Software\IBExpert\ibexpert.udb. This area is user-dependent and even if several users work on one machine, each user has their own file.

If you are still using the old ibexpert.stg (default path: \Documents and Settings\<user>\Application Data\HK-Software\IBExpert\IBExpert.stg) then copy this.

New payment processing partner paddle.com

Dear IBExpert Software Customer,

We wanted to inform you that we are currently transitioning our payment processing partner from Digital River/MyCommerce to Paddle. As a result, you may notice some changes to our payment pages, and you will now receive invoices from Paddle instead of Digital River/MyCommerce.

During this transition period, there may be some technical issues or disruptions. Please rest assured that we are working diligently to minimize any inconvenience for you.

If you need to order your product, please use the product price list page here.

If you experience any difficulties with ordering, receiving license information, or obtaining invoices, please do not hesitate to reach out to us at register@ibexpert.net. We are here to assist you and ensure a smooth transition.

If you order for a company in Europe and have a valid European VAT ID, you can also send your order request by email to register@ibexpert.net and we will send you an invoice which can be paid by IBAN bank account transfer. Orders outside Europe or without a VAT ID must use the paddle purchase links. 

Best regards,

The IBExpert Team       

Firebird Schreibvorgaenge

English-language version

Warum die Reihenfolge von Schreibvorgängen für Firebird so wichtig ist

Holger Klemt, September 2026

(PDF Download)

Die Zuverlässigkeit einer Firebird-Datenbank hängt nicht nur von Firebird selbst ab. Ebenso wichtig ist, dass das darunterliegende Betriebssystem und Storage-System Schreibvorgänge so ausführen und bestätigen, wie es die Datenbank erwartet. 

Firebird ist darauf ausgelegt, Änderungen in einer definierten und sorgfältig abgestimmten Reihenfolge auf den Datenträger zu schreiben. Besonders bei aktiviertem Forced Writes stellt Firebird sicher, dass kritische Änderungen tatsächlich auf ein dauerhaftes Speichermedium geschrieben wurden, bevor nachfolgende Operationen als erfolgreich abgeschlossen gelten. 

Caches und zusätzliche Storage-Schichten 

Moderne Betriebssysteme, RAID-Controller und Storage-Systeme versuchen Schreibzugriffe aus Performancegründen zu optimieren. Schreibvorgänge können beispielsweise gesammelt, zusammengefasst oder in einer anderen Reihenfolge an das physische Speichermedium weitergegeben werden. 

Das ist grundsätzlich sinnvoll und bei normalem Dateizugriff meist unproblematisch. Für ein Datenbanksystem ist jedoch entscheidend, dass sogenannte Flush- oder Synchronisationsanforderungen zuverlässig bis zum tatsächlichen Datenträger durchgereicht werden. 

Kritisch können deshalb zusätzliche Schichten zwischen Firebird und dem physischen Datenträger sein, zum Beispiel: 

• Host- oder Controller-Caches 
• RAID- und Storage-Virtualisierung 
• Cluster-Dateisysteme 
• Block-Level-Replikation
• SAN- oder NAS-Systeme 
• Snapshots und andere Virtualisierungsschichten 
• nicht batterie- oder flashgesicherte Schreib-Caches

Das Problem entsteht insbesondere dann, wenn eine Schicht einen Schreibvorgang bereits als abgeschlossen meldet, obwohl die Daten noch nicht dauerhaft gespeichert wurden. 

Was bei einem Absturz passieren kann 

Bei einem Stromausfall, Kernel-Crash oder Hardwarefehler können dadurch bereits bestätigte Schreibvorgänge verloren gehen. 

Besonders problematisch ist dies, wenn ein späterer Datenbankzustand bereits auf dem Datenträger angekommen ist, während dazugehörige vorherige Änderungen noch in einem Cache liegen. Dann können innerhalb der Datenbankdatei Informationen entstehen, die nicht mehr zueinander passen. 

Genau die von Firebird vorgesehene Schreibstrategie soll solche Situationen verhindern. Voraussetzung dafür ist allerdings, dass Betriebssystem, Treiber, Controller und Storage die entsprechenden Synchronisations-anforderungen korrekt umsetzen. 

Forced Writes abzuschalten kann deshalb zwar die Schreibperformance deutlich erhöhen, reduziert aber gleichzeitig eine wichtige Sicherheitsfunktion der Datenbank.

Linux ist nicht automatisch vor solchen Problemen geschützt 

Linux-Dateisysteme wie ext4 verfügen über Mechanismen zur kontrollierten Reihenfolge und Absicherung von Schreibvorgängen. Das bedeutet jedoch nicht automatisch, dass jede darunterliegende Storage-Konfiguration dieselben Garantien bietet. 

Sobald zusätzliche Cluster-, Mirror-, RAID- oder Virtualisierungsschichten beteiligt sind, muss sichergestellt werden, dass Flushes und Write Barriers auch tatsächlich bis zum persistenten Speichermedium weitergegeben werden. 

Für Datenbanksysteme ist daher weniger entscheidend, ob Windows oder Linux eingesetzt wird, sondern ob die gesamte Storage-Kette die vom Datenbanksystem verlangten Garantien zuverlässig einhält. 

Ein Beispiel aus der Praxis 

In einem von uns betreuten Umfeld kam es vor einigen Jahren bei einem geschäftskritischen Firebird-System zu einem schweren Ausfall. Die Datenbank befand sich auf einer extern aufgebauten Linux-Cluster- und Storage-Lösung. 

Nach einem Fehler waren nicht nur die produktive Datenbank, sondern auch die auf Storage-Ebene erzeugte Kopie betroffen. Die Wiederherstellung des Systems erforderte erhebliche Analyse- und Reparaturarbeiten. 

Anschließend wurde die Architektur geändert. Seitdem erfolgt die Redundanz nicht mehr durch eine transparente Spiegelung der geöffneten Datenbankdatei, sondern durch eine Replikation auf Firebird-Ebene auf unabhängige Serversysteme. Diese Architektur ist dort seit vielen Jahren zuverlässig im Einsatz. 

Redundanz möglichst auf Datenbankebene 

Für Firebird-Systeme bevorzugen wir deshalb möglichst einfache und nachvollziehbare Storage-Strukturen. 

Redundanz und Hochverfügbarkeit sollten nach Möglichkeit so realisiert werden, dass zwei unabhängig arbeitende Firebird-Server jeweils ihre eigene lokale Datenbankdatei besitzen und die Synchronisation kontrolliert auf Datenbankebene erfolgt. 

Das hat mehrere Vorteile: 

• Jeder Firebird-Server kontrolliert seine eigene Datenbankdatei. 
• Storage-Probleme eines Systems werden nicht automatisch auf eine zweite Datenbankdatei übertragen. 
• Die Anzahl zusätzlicher Cache- und Virtualisierungsschichten wird reduziert. 
• Fehler lassen sich leichter analysieren und eingrenzen. 
• Die für die Datenintegrität wichtigen Schreibmechanismen von Firebird bleiben erhalten. 

Sicherheit und Performance sind kein Widerspruch 

Die konsequente Einhaltung der notwendigen Schreibreihenfolge erzeugt zwangsläufig eine gewisse Latenz. Gerade bei sehr schreibintensiven Anwendungen kann diese deutlich messbar sein. 

Diese zusätzliche Latenz ist jedoch kein unnötiger Performanceverlust, sondern ein wesentlicher Bestandteil der Transaktionssicherheit. 

Bei der Optimierung eines Firebird-Servers sollte deshalb nicht versucht werden, diese Sicherheits-mechanismen zu umgehen. Sinnvoller ist es, die Hardware und Storage-Architektur so auszulegen, dass synchrone Schreibvorgänge möglichst schnell ausgeführt werden können. 

Eine schnelle Datenbank benötigt schnelles Storage. Eine zuverlässige Datenbank benötigt jedoch vor allem Storage, dessen Zusagen über erfolgreich gespeicherte Daten auch tatsächlich stimmen.