Viele Delphi-Fachanwendungen sind mit Paradox-Tabellen und der Borland Database Engine (BDE) entstanden, weil das damals ein pragmatischer Standard war: lokal, schnell startklar, wenig Infrastruktur. In der Praxis laufen diese Systeme oft bis heute produktiv – inklusive Reporting, Etikettendruck, Import/Export, Batch-Jobs, Historientabellen und Sonderlogik, die sich über Jahre in den Datenzugriff „hineingearbeitet“ hat. Genau deshalb ist eine Migration nicht nur ein Export der Daten, sondern ein kontrollierter Umbau: Datenmodell, SQL-Verhalten, Nebenwirkungen im Code und Betriebsprozesse müssen zusammen betrachtet werden.
MariaDB ist als Zielplattform häufig eine sehr gute Wahl, wenn es um einen robusten Mehrbenutzerbetrieb, saubere Transaktionen, zentrale Backups, Replikation, eine klare Rechteverwaltung und die Anschlussfähigkeit für Web-Portale, Services oder REST-APIs geht. Die Herausforderung ist dabei selten die Datenbankinstallation – der eigentliche Aufwand liegt im sicheren Migrationspfad: Wie werden Tabellen, Indizes, Primary Keys, Zeichensätze, Datumsfelder, „leere“ Werte und referenzielle Beziehungen korrekt überführt, ohne dass die Fachlogik im laufenden Betrieb bricht?
Dieser Beitrag beschreibt eine bewährte Vorgehensweise, um Paradox und BDE kontrolliert nach MariaDB zu migrieren: technisch fundiert, stufenweise und mit Fokus auf Stabilität. Ziel ist eine tragfähige Grundlage für weitere Modernisierungsschritte – beispielsweise BDE-Ablösung, Umstieg auf BDE-Ablosung mit nativer Anbindung, klare Layer-3 Architektur, REST-Server und plattformfähige Clients.
Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel
Paradox als Dateiformat und die BDE als Zugriffsschicht bilden ein Gesamtsystem mit Eigenheiten, die man in MariaDB nicht 1:1 „nachbauen“ sollte. Typische Symptome im Alltag sind:
- Intransparente Abhängigkeiten: SQL-Statements sind verteilt (Forms, DataModules, Reports, dynamische String-SQL), oft ohne zentrale Governance.
- Verhalten „nach Gefühl“: Bestimmte Filter, Sortierungen oder Joins funktionieren zufällig, weil Paradox/BDE tolerant ist oder implizit typkonvertiert.
- Mehrbenutzer-Grenzen: Dateibasierte Sperren, Performanceeinbrüche im Netz, Locking-Probleme bei wachsendem Datenvolumen.
- Wartungsrisiken: BDE-Abhängigkeiten, alte Treiber, schwieriges Deployment auf modernen Windows-Versionen, 64‑Bit/ARM64-Themen.
Eine kontrollierte Migration nimmt diese Punkte nicht als Nebeneffekt, sondern als Zielkriterien. MariaDB wird dabei nicht nur „neue Datenbank“, sondern die Chance, die Datenzugriffsschicht zu entkoppeln, fachliche Integrität zu erhöhen und Schnittstellenfähigkeit herzustellen.
Zielbild: MariaDB als stabile Datenbasis für Desktop, Services und Portale
Ein sinnvolles Zielbild für B2B-Fachanwendungen besteht meist aus drei Ebenen:
- Datenbank (MariaDB): konsistente Datenhaltung, Indizes, Constraints, Transaktionen, Benutzer/Rollen, Backups.
- Fachlogik (Server/Services): Validierungen, Workflows, Importer, Scheduler, Schnittstellen. Optional als REST-Server, Windows- oder Linux-Services.
- Clients (VCL/FMX/Web): Bedienoberflächen, Reports, Offline-Teile, Integrationen. Idealerweise mit klaren Verträgen zur Fachlogik.
Je nach Ausgangslage muss nicht alles sofort umgesetzt werden. Aber die Migration sollte so geplant sein, dass sie den Weg zu einer sauberen Architektur nicht verbaut. Wer heute nur Tabellen kopiert und morgen wieder „direkt“ aus jedem Formular auf die Datenbank schreibt, hat zwar MariaDB eingeführt, aber die eigentlichen Risiken bleiben.
Bestandsaufnahme: Was wirklich migriert werden muss
Am Anfang steht eine Inventur, die über „wie viele Tabellen“ hinausgeht. In Paradox/BDE-Projekten ist es typisch, dass die Datenbank nur ein Teil der Wahrheit ist. Wichtige Punkte:
1) Tabellen, Indizes, „Pseudo-Schlüssel“
Häufig fehlen echte Primary Keys. Stattdessen existieren Kombinationen aus Feldern, laufende Nummern ohne eindeutige Constraint oder „Key“-Felder, die in der Anwendung gepflegt werden. Für MariaDB müssen daraus eindeutige, belastbare Schlüssel werden – sonst sind Transaktionen und referenzielle Integrität nur begrenzt wirksam.
2) Queries, dynamische SQL-Bausteine, Reports
BDE nutzt je nach Komponente unterschiedliche SQL-Dialekte und toleriert „kreative“ Statements. Reporting-Komponenten (auch ältere) enthalten oft eigene SQL-Definitionen. Eine Migration muss diese Quellen finden und kategorisieren: kritische Kern-Queries, selten genutzte Auswertungen, Spezialimporte.
3) Zeichensatz und Sonderzeichen (Umlaute, ISO/ANSI, Unicode)
Viele Paradox-Anwendungen sind historisch ANSI-basiert. Wenn die Delphi-Anwendung selbst irgendwann auf Unicode umgestellt wurde, entstehen Mischwelten: Daten liegen in altem Encoding, UI ist Unicode, Exporte erwarten Windows-1252. MariaDB sollte hier ein klares Konzept bekommen (typischerweise utf8mb4), inklusive sauberer Konvertierung und Tests auf „unsichtbare“ Fehler (Vergleiche, Sortierung, Trim/Pad, Sonderzeichen).
4) „Leere“ Werte, Null-Logik und Datumsfelder
Paradox/BDE kennt diverse Sonderfälle: leere Strings statt NULL, 0-Daten, „leere“ Timestamps, Defaultwerte, die in der UI entstehen. MariaDB unterscheidet strikt zwischen NULL und leer. Das beeinflusst WHERE-Klauseln, Aggregationen und Berechnungen. Diese Unterschiede müssen pro Tabelle/Feld bewertet werden.
5) Nebenartefakte: Session-Tabellen, lokale Konfiguration, Cache
Oft liegen in der Paradox-Struktur lokale Tabellen für Zwischenergebnisse, Export-Puffer, Benutzer-Layouts oder Parameter. Manches gehört weiterhin lokal (z. B. UI-Layouts), anderes gehört zentral (z. B. Arbeitsvorgänge, Status, Logs). Eine Migration ist eine Gelegenheit, diese Kategorien sauber zu trennen.
Stolpersteine bei Paradox/BDE: typische technische Unterschiede
Damit Migration planbar wird, lohnt es sich, die wiederkehrenden Unterschiede explizit zu adressieren.
SQL-Dialekt und Operatoren
BDE/Paradox-SQL ist nicht identisch mit MySQL/MariaDB-SQL. Unterschiede treten u. a. bei Datumsfunktionen, Stringfunktionen, Outer Joins (historisch), Like/Maskenlogik und bei impliziten Typkonvertierungen auf. Ein kontrollierter Ansatz ersetzt „funktioniert schon“ durch klare Regeln: Welche Statements werden portiert, welche werden bewusst neu geschrieben, welche werden in Views/Stored Procedures gekapselt (falls sinnvoll)?
Sortierung und Collation
In Paradox sind Sortierreihenfolgen und Groß-/Kleinschreibung oft anders als in MariaDB, insbesondere bei Umlauten. In MariaDB entscheidet die Collation (z. B. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) über Vergleich und Sortierung. Das ist keine akademische Frage: Es beeinflusst Deduplizierung, „Suche“-Funktionen und das Verhalten von Unique-Constraints.
Autoincrement und Nummernkreise
Paradox hat Autoincrement-Felder, aber Anwendungen nutzen häufig eigene Nummernkreise (belegnummern, auftragsnummern) mit Sonderlogik. In MariaDB sollte sauber getrennt werden:
- Technischer Primärschlüssel: AUTO_INCREMENT (oder UUID, je nach Architektur) für Beziehungen.
- Fachliche Nummer: eigener Nummernkreis mit Transaktionsschutz, ggf. pro Mandant/Periode.
Wer versucht, eine fachliche Nummer als technischen Key zu missbrauchen, handelt sich später teure Umbauten ein.
Locking und Transaktionen
Der Sprung von dateibasiertem Zugriff zu einem echten Server ist ein Gewinn, aber er verändert das Verhalten. In MariaDB sind Transaktionen (InnoDB) zentral. Man muss entscheiden, wo Transaktionsgrenzen liegen: pro Dialog, pro Speichervorgang, pro Batch. Besonders wichtig: Lange Transaktionen und „Edit-Modus“ über Minuten sind in Paradox-Welten verbreitet, aber serverseitig kritisch (Locks, Deadlocks, Replikationslag). Hier ist eine Anpassung der Arbeitsweise oder des UIs häufig Teil der Migration.
Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang
In B2B-Umgebungen ist Betriebsstabilität oft wichtiger als ein schneller Schnitt. Ein stufenweiser Migrationspfad reduziert Risiko, weil Fachbereich und IT iterativ validieren können.
Etappe 1: Datenmodell-Transfer mit Mapping, ohne Code-Umbau
Im ersten Schritt wird ein MariaDB-Schema aufgebaut, das die Paradox-Struktur abbildet – aber bereits mit Zielprinzipien: Primary Keys, Indizes, sinnvolle Datentypen, utf8mb4, InnoDB. Parallel wird ein reproduzierbarer Importprozess erstellt (Skripte/Tools), der bei Bedarf wiederholt werden kann. Wichtig ist hier die Wiederholbarkeit, weil Migration nie beim ersten Lauf „fertig“ ist.
Deliverables dieser Etappe sind typischerweise:
- Schema-Definition (DDL) versioniert (z. B. in Git)
- Feldmapping-Liste (Paradox → MariaDB) inkl. Konvertierungsregeln
- Import-Prozedur mit Protokollierung (Anzahl Datensätze, Fehler, Ausreißer)
- erste Validierungsreports (Counts, Summen, Checksummen)
Etappe 2: BDE-Ablösung im Datenzugriff (z. B. mit FireDAC)
Der eigentliche Modernisierungsschritt ist die Entkopplung von der BDE. In Delphi-Projekten ist BDE-Ablosung mit nativer Anbindung ein bewährter Weg, weil es moderne Treiber, Transaktionen, Parameterbindung und einheitliche Komponenten für unterschiedliche SQL-Backends bietet. Entscheidend ist nicht „BDE raus“, sondern wie der Code danach aussieht: zentraler Datenzugriff, klare Fehlerbehandlung, saubere Parameter statt String-Konkatenation.
Typische Aufgaben in dieser Etappe:
- Ersetzen von TTable/TQuery durch FireDAC-Queries und DataSets
- Einführen einer Data-Access-Schicht (DAL) als Basis für spätere Layer-3 Architektur
- Standardisieren von Transaktions-Scopes (Commit/Rollback)
- SQL-Review: Dialektanpassung, Parameter, Paging, Joins
Wenn Ihre Anwendung langfristig modernisiert werden soll, ist dieser Schritt oft wichtiger als die reine Datenmigration. Er schafft die technische Freiheit für 64‑Bit, moderne Windows-Versionen und saubere Deployment-Pipelines.
Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch
Für kritische Systeme ist ein Parallelbetrieb sinnvoll: MariaDB wird aufgebaut und zyklisch (oder inkrementell) befüllt, während das Altsystem weiterläuft. Dadurch kann der Fachbereich Auswertungen vergleichen, Randfälle identifizieren und die neue Plattform unter Last testen. Der Parallelbetrieb kann unterschiedlich umgesetzt werden:
- Read-only-Replik für Reporting/BI-Vorbereitung
- „Dual Write“ in definierten Teilbereichen (nur wenn gut beherrscht)
- Stichtagsmigration mit mehreren Trockenläufen und klarer Cutover-Checkliste
Wichtig ist, die Komplexität nicht zu überziehen: Dual-Write klingt attraktiv, ist aber fehlerträchtig, wenn die Fachlogik nicht zentralisiert ist. Oft ist ein wiederholbarer Stichtagslauf mit guter Validierung am Ende wirtschaftlicher.
Etappe 4: Optimierung, Integrität, Performance, Betriebsprozesse
Nach dem Cutover beginnt die Phase, in der MariaDB seine Stärken ausspielen soll: referenzielle Integrität, performante Indizes, saubere Rechte, Monitoring, Backup/Restore-Tests. Hier werden häufig erst die „echten“ Produktionslasten sichtbar: lange Reports, schlecht indizierte Suchmasken, Batch-Updates. Eine kontrollierte Migration plant diese Etappe explizit ein, statt sie als ungeplante Nacharbeit entstehen zu lassen.
Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust
Das Feldmapping ist das Herz der Migration. Typische Zuordnungen (vereinfacht) sind:
- Alpha / Memo: VARCHAR/TEXT (mit utf8mb4), Längenprüfung und Trim-Regeln
- Number: INT/BIGINT/DECIMAL je nach Wertebereich; Vorsicht bei impliziten Nachkommastellen
- Date/Time: DATE/DATETIME/TIMESTAMP; klare Regeln für „0-Datum“ bzw. NULL
- Logical: BOOLEAN bzw. TINYINT(1) mit eindeutiger Semantik
- Currency: DECIMAL(… ,2/4) statt Float, um Rundungsfehler zu vermeiden
Wichtig ist, nicht nur Datentypen zu übersetzen, sondern auch fachliche Regeln festzuhalten: Darf ein Feld NULL sein? Welche Defaultwerte sind fachlich korrekt? Welche Kombinationen müssen eindeutig sein? Daraus ergeben sich Constraints und Indizes. Diese Regeln waren im Paradox/BDE-System oft implizit in der UI oder im Code versteckt – in MariaDB sollten sie, wo sinnvoll, explizit werden.
Integrität: Primary Keys, Foreign Keys und eindeutige Indizes nachziehen
Viele Legacy-Datenbanken funktionieren jahrelang ohne referenzielle Integrität – bis Integrationen, Portale oder parallele Prozesse dazukommen. Spätestens dann wird die Datenqualität zum limitierenden Faktor. In MariaDB lassen sich Foreign Keys, Unique Constraints und Checks (je nach Version/Engine) einsetzen, um Datenfehler frühzeitig zu verhindern.
Ein praktikabler Weg ist, Integrität stufenweise einzuführen:
- Zuerst Primary Keys und eindeutige Indizes auf Kernobjekte (Kunden, Artikel, Belege)
- Dann Foreign Keys in den stabilen Bereichen
- Für „historische“ Tabellen mit Datenmüll: erst Bereinigung, dann Constraints
Das senkt das Risiko, dass der Cutover an Altlasten scheitert, und verbessert dennoch die Gesamtlage deutlich.
Performance in der Praxis: was sich mit MariaDB ändert
Paradox/BDE-Systeme sind oft auf „Datei-Schnelligkeit“ optimiert: lokale Indizes, schnelle Tabellenzugriffe, viel clientseitige Filterung. Bei MariaDB verlagert sich die Arbeit auf den Server. Das ist gut, erfordert aber saubere SQL- und Index-Strategien.
Typische Performance-Fallen
- SELECT * aus großen Tabellen, weil früher „lokal“ schnell genug
- Clientseitiges Filtern statt serverseitiger WHERE-Klauseln
- Fehlende zusammengesetzte Indizes auf Suchmaskenfelder (z. B. Mandant + Status + Datum)
- LIKE ‚%text%‘ ohne geeignete Volltextstrategie
Messbar verbessern statt „nach Gefühl“
Eine kontrollierte Migration etabliert früh Messpunkte: Slow Query Log, Explain-Analysen, reproduzierbare Lasttests. Das ist besonders wichtig, wenn nach der Migration weitere Komponenten geplant sind, etwa ein REST-Server oder ein Kundenportal, das neue Zugriffsmuster erzeugt (viele kleine Requests, Paging, Suchendpunkte).
Delphi-spezifisch: BDE-Ablösung, FireDAC und saubere Zugriffsschichten
In Delphi-Projekten ist die technische Modernisierung eng mit dem Datenzugriff verbunden. Die BDE ist nicht nur „ein Treiber“, sondern ein kompletter Zugriffsstil (TTable, recordbasiert, Navigieren, lokale Filter). Eine Migration nach MariaDB ist der richtige Moment, um den Zugriff zu konsolidieren.
Von „DataSets überall“ zu kontrolliertem Datenzugriff
Viele Anwendungen haben in jeder Form eigene Queries. Das skaliert fachlich und sicherheitstechnisch schlecht. Bewährt ist eine Umstellung in Richtung:
- Zentrale Repository-/Service-Klassen für Kernobjekte
- Einheitliche Fehler- und Transaktionsbehandlung
- Parametrisierte Queries (SQL Injection vermeiden, Plan-Caching nutzen)
- Konfigurierbare Connection-Pools bzw. Connection-Management für Services
Damit entsteht eine Grundlage für eine Layer-3 Architektur, in der UI, Fachlogik und Persistenz sauber getrennt sind. Das hilft nicht nur beim Datenbankwechsel, sondern auch beim späteren Ausbau in Richtung REST-Server oder Hintergrunddienste.
MariaDB-Anbindung mit FireDAC: was typischerweise zu klären ist
In Projekten tauchen immer wieder dieselben Fragen auf: Welche Treibervariante (MySQL/MariaDB), welche SSL-Optionen, welche Timezone- und Datumsoptionen, welche Unicode-Settings? Das sind keine Details, weil sie direkt Einfluss auf Datenkonsistenz (Datum/Zeit), Sortierung und Betriebssicherheit (TLS) haben. Eine kontrollierte Migration legt diese Parameter fest, dokumentiert sie und testet sie mit realistischen Daten.
Cutover-Plan: Stichtag, Datenfreeze, Rollback – ohne Überraschungen
Der Cutover ist ein Projekt für sich. Ein guter Cutover-Plan beschreibt nicht nur „wann umschalten“, sondern auch die Schutzmaßnahmen:
- Datenfreeze: Ab wann werden im Altsystem keine Daten mehr erfasst? Gibt es Notfallprozesse?
- Finaler Import: Wie lange dauert er realistisch? (Trockenläufe liefern Zahlen.)
- Validierung: Welche Checks müssen vor Freigabe grün sein (Counts, Summen, Stichproben, fachliche Reports)?
- Rollback: Wann wird abgebrochen, und wie geht es dann weiter?
- Kommunikation: Wer gibt frei? Wer ist im War Room erreichbar?
Gerade im Mittelstand ist ein „Rollback“ oft nicht technisch, sondern organisatorisch kritisch. Deshalb muss die Migration so vorbereitet sein, dass der Cutover kein Experiment ist, sondern ein geprobter Ablauf.
Nach der Migration: Basis für REST, Services und Multiplattform
Wenn MariaDB stabil läuft und die BDE-Ablösung sauber umgesetzt ist, entstehen neue Optionen: REST-APIs für externe Systeme, Hintergrundverarbeitung als Windows- oder Linux-Services, Entkopplung von UI und Fachlogik sowie perspektivisch Multiplattform-Clients. Besonders häufig ist der nächste Schritt, Fachlogik aus dem Desktop herauszuziehen, um Integrationen (ERP/DMS/CRM) und Portale kontrolliert zu bedienen.
Wichtig ist dabei: Ein REST-Server ist keine „zusätzliche Schicht“, sondern ein Architekturentscheid. Wer Datenzugriff, Validierung und Berechtigungen bereits in Services/Repositories konsolidiert hat, kann daraus deutlich leichter robuste APIs entwickeln.
Praxis-Checkliste: Was Sie vor Projektstart klären sollten
- Welche Module sind geschäftskritisch und müssen am Cutover-Tag sicher laufen?
- Wie sehen reale Datenvolumina aus (Tabellengrößen, Wachstum, Archivkonzepte)?
- Welche Reports müssen 1:1 identisch sein, welche dürfen verbessert werden?
- Welche Integrationen hängen am System (Dateiexporte, ODBC, Office, Druckstrecken)?
- Gibt es Mandantenfähigkeit, und wenn ja: wie ist sie heute abgebildet?
- Welche Betriebsanforderungen gelten (Backupfenster, Restore-Zeit, Rechte, Audit)?
Diese Klärungen sind nicht Bürokratie, sondern verhindern, dass eine Migration „technisch fertig“ ist, aber fachlich nicht abgenommen werden kann.
Fazit: Kontrolliert migrieren heißt Risiken planbar machen
Paradox und BDE kontrolliert nach MariaDB zu migrieren bedeutet, die Anwendung als Gesamtsystem zu modernisieren: Datenmodell, SQL, Transaktionen, Zeichensätze, Zugriffsschicht und Betriebsprozesse. Wer den Wechsel als reinen Export betrachtet, bekommt meist genau die Probleme, die man eigentlich loswerden wollte – nur auf einem neuen Server.
Ein stufenweises Vorgehen mit reproduzierbarem Import, sauberem Feldmapping, früher Validierung und einer klaren BDE-Ablösung (z. B. über FireDAC) schafft dagegen eine stabile Basis: für Mehrbenutzerbetrieb, für Integrationen, für Services und für die nächsten Schritte der Delphi Modernisierung.
Wenn Sie Ihre Migration fachlich sicher planen und ohne Betriebsbruch umsetzen wollen, besprechen wir gern Ausgangslage, Risiken und einen realistischen Etappenplan: https://net-base-software-gmbh.de/kontakt/