Borland BDE pakeitimas FireDAC: vadovas, kaip saugiai modernizuoti Delphi be Big Bang

Daugelio įmonių veikloje Borland Database Engine (BDE) iki šiol yra verslui kritinių Delphi-programų dalis: sukaupta domeno logika, su vartotojo sąsaja susijusios duomenų prieigos su TTable/TQuery, kartais vis dar Paradox/dBase, kartais ankstyvos klientų/serverių instaliacijos. Dažna realybė: programinė įranga veikia, vartotojai pažįsta procesus ir kasdieniame darbe nėra tiesioginio motyvo „ką nors keisti“. Tuo pačiu keičiasi techninis pagrindas: operacinių sistemų saugumas stiprinamas, diegimo procesai standartizuojami, 64‑bit palaikymas tampa lūkesčiu, o duomenų saugojimas turėtų vykti duomenų bazių serveriuose su aiškiai apibrėžtomis teisėmis ir atsarginių kopijų strategija.

Būtent čia „Borland BDE durch BDE-Ablösung mit nativer Anbindung ersetzen“ tampa strateginiu modernizacijos uždaviniu. BDE-Ablosung mit nativer Anbindung yra dabartinėse Delphi versijose įtvirtintas duomenų prieigos sluoksnis šiuolaikinėms duomenų bazėms. Jis suteikia nuoseklų elgesį, patvarius tvarkyklius, Unicode palaikymą, monitoringą/tracing’ą ir architektūrą, kuri aptarnauja tiek darbalaukio klientus, tiek paslaugas ir REST-serverius. Tačiau perėjimas retai būna vien tik 1:1 komponentų pakeitimas – ypač kai esama sistema per metus „įkainojo“ BDE-specifinį elgesį (transakcijų prielaidos, duomenų formatai, filtrai/rūšiavimai, Cached Updates, Third-Party-Reports).

Šis straipsnis susitelkia į praktinį vykdymą: kaip pakeisti BDE į FireDAC nekenkiant domeno logikai ir be būtinybės vykdyti Big‑Bang perėjimo? Pateikiami įgyvendinami modeliai, techniniai tikslai ir nurodymai dėl tipinių probleminių zonų įmonės eksploatacijoje.

Warum die BDE-Ablösung heute mehr als Technikpflege ist

Kol BDE programa veikia, jos pakeitimas kartais atrodo kaip grynas „kodo sutvarkymas“. Praktikoje spaudimą dažniau sukelia eksploatavimo ir rizikos klausimai.

Deployment, Security-Baselines und „No-Touch“-Clients

BDE istoriškai orientuota į lokalią konfigūraciją (BDE Administrator, Alias-Definitionen, NetDir, gemeinsame Konfigurationsdateien). Moderne Umgebungense manuellen Schritten und maschinenweiten Einstellungen schwer vereinbar mit Softwareverteilung, Härtung und Auditierbarkeit. FireDAC leidžia kur kas labiau kontroliuojamus diegimus, nes prisijungimo parametrai ir tvarkyklių nustatymai gali būti valdomi arti programos.

64‑Bit, Windows-Modernisierung und neue Plattformziele

Spalstyti jei programa turi veikti 64‑bit (atminties poreikiai, tvarkyklių/Office ekosistema, nauja aparatinė įranga, terminal server strategijos), BDE tampa realiu blokuotoju. FireDAC palaiko 32/64‑bit nuosekliai ir yra pagrindinis komponentas kiekvienoje Delphi Modernisierung, kuri techniškai negali žlugti dėl duomenų prieigos. Be to, temos kaip Windows 11 ARM64 ir hibridinės klientų/paslaugų architektūros tampa tiksliai planuojamos.

Datenbankstrategie: weg von dateibasiert, hin zu serverbasiert

Daugelis BDE-programų vis dar neša Paradox/dBase paveldą. Šios failų pagrindu veikiančios duomenų bazės daugiau vartotojų aplinkose yra pažeidžiamesnės, administraciniu požiūriu sunkiau apsaugomos ir prastai atitinka šiandieninius reikalavimus (vaidmenys/teisės, šifravimas, monitoringas, aukštas prieinamumas). FireDAC nėra „naujas Paradox‑tvarkyklė“, bet tai modernus prieigos kelias prie SQL Server, PostgreSQL, MariaDB ir Firebird. Praktikoje BDE pakeitimas dažnai yra signalas profesionalizuoti duomenų saugojimą ir eksploatavimą.

Wartbarkeit und Diagnosefähigkeit im Betrieb

Neįvertintas sąnaudas generuoja klaidų paieška: epizodiniai blokavimai, nekonsistentus kursorų elgesys, sunkiai sekami parametrų konvertavimai ar tinklo/kelių problemos. FireDAC su logavimu, monitoring’u ir aiškesniu tipų elgesiu suteikia geresnes prielaidas reprodukuojamai klaidų analizei. Įmonėms, kurios ketina ilgalaikiai eksploatuoti ir punktualiai plėsti programą, tai yra tiesioginė nauda.

BDE vs. FireDAC: Unterschiede, die in der Migration zählen

Formaliai komponentus galima priskirti vienas prie kito. Realioje migracijoje svarbūs elgesio pokyčiai, kurie gali sukelti domenines pasekmes. Trumpa orientacija:

Komponenten-Mapping (als Startpunkt)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (in Modernisierungen oft besser: Query-/View-basierter Zugriff)
• TStoredProc (BDE) → TFDStoredProc

Die häufigsten Verhaltensdifferenzen

• Parameter und Datentypen: FireDAC arbeitet präziser. „Wird schon gehen“-SQL fällt schneller auf (z. B. Datumswerte als Strings, implizite Konvertierungen, unklare Nullability).
• Transaktionen: Legacy-Code enthält oft implizite Commit-Annahmen (Dataset schließen, AutoCommit-ähnliche Muster, Cached Updates). Bei FireDAC lohnt sich bewusste Transaktionssteuerung, weil sie fachliche Konsistenz verbessert.
• Cursor/Fetch: FireDAC hat andere Defaults und mehr Stellschrauben. Ineffiziente Muster (große Resultsets für UI-Listen) werden sichtbarer, können aber gezielt optimiert werden.
• Unicode: In modernen Delphi-Versionen ist Unicode Standard. Die FireDAC-Kette (Client-Library, Connection-Optionen, DB-Collation, Feldtypen) muss konsistent sein, sonst drohen Zeichen- und Vergleichsprobleme.
• Deployment: Je nach DB werden Client-Bibliotheken benötigt (z. B. libpq für PostgreSQL). Das muss früh geplant werden, sonst entstehen produktionsnahe Überraschungen.

Zielbild für eine FireDAC-Architektur: stabil, testbar, erweiterbar

Eine BDE-Ablösung sollte nicht in „FireDAC überall irgendwie“ enden. Ein tragfähiges Zielbild ist besonders dann wertvoll, wenn die Anwendung weiterentwickelt oder in Services/Portale eingebettet werden soll.

Minimalziel: einheitlicher Connection-Layer

Statt verteilter Verbindungen in Formularen empfiehlt sich ein zentraler Connection-Layer:

• Erzeugung und Konfiguration von TFDConnection an einer Stelle
• Einheitliche Timeouts, Encoding/CharacterSet, Fehlerhandling
• Umschaltung Dev/Test/Prod ohne manuelle Nacharbeit
• Optional: zentrale Aktivierung von Tracing/Monitoring für Diagnosefälle

Empfohlen: klare Transaktionsgrenzen in der Fachlogik

Viele Altanwendungen verteilen Datenänderungen über UI-Events. Das erhöht das Risiko von Teilupdates und erschwert Tests. Ein stabiler FireDAC-Ansatz ist: Der Use Case (Service/Fachlogik) startet und beendet die Transaktion, nicht die UI. Auch bei einer reinen VCL-Desktopsoftware entsteht so ein robuster Kern, der später leichter als Service oder API nutzbar ist.

Erweiterungsfähig Richtung Services und REST

Wer später einen REST-Server ergänzt, Windows- oder Linux-Services betreibt oder ein Kundenportal anbinden will, profitiert von einem sauberen Datenlayer. FireDAC ist dafür geeignet, wenn Connection-Management, Fehlerbehandlung und – je nach Server-Last – Pooling zumindest als Zielbild mitgedacht werden. Das muss nicht im ersten Schritt umgesetzt sein, sollte aber die Architektur nicht blockieren.

Migrationsstrategie: FireDAC schrittweise einführen, BDE kontrolliert zurückbauen

In B2B-Umgebungen ist ein Big Bang selten realistisch: zu viele Fachprozesse, zu viel Betriebsverantwortung, zu wenig Akzeptanz für lange Downtimes. Eine schrittweise BDE-Ablösung ist in der Regel der sichere Weg.

Phase 1: Bestandsaufnahme und Risikokarte

Eine brauchbare Inventur zählt nicht nur Komponenten, sondern bewertet Verhalten und Kopplungen:

• Welche Datenbank(en) werden genutzt: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Wo hängen TTable-Zugriffe, wo wird SQL per TQuery genutzt, wo Stored Procedures?
• Wie werden Transaktionen heute gelebt (explizit, implizit, Cached Updates, gemischte Muster)?
• Welche Reports/Exports erwarten bestimmte Dataset-Eigenschaften (Sortierung, Filter, Calculated Fields)?
• Welche Drittkomponenten oder Eigenframeworks sind BDE-spezifisch?

Aus dieser Karte ergibt sich, ob die Ablösung „nur“ den Zugriff betrifft oder ob parallel ein Datenbank-Umbau (z. B. Paradox → SQL Server/PostgreSQL/MariaDB) sinnvoll oder zwingend ist.

Phase 2: FireDAC-Foundation (ohne UI-Umstellung)

Bevor Sie Screens migrieren, sollte FireDAC technisch sauber stehen:

• Zentrales DataModule oder Service-Klasse mit TFDConnection
• Konfigurationsmodell für Connection Strings (z. B. INI/JSON) und saubere Secrets-Verwaltung
• Standardisierte Fehlerbehandlung (DB-Exceptions in verständliche, logbare Meldungen überführen)
• Tracing/Monitoring-Optionen für Pilotbetrieb (gezielt aktivierbar, nicht dauerhaft „laut“)

Wichtig ist, dass daraus verbindliche Standards entstehen: Namenskonventionen, Parameterregeln, Logging-Schema, Default-Einstellungen pro Datenbank.

Phase 3: Pilotmodul mit echter Fachrelevanz

Ein guter Pilotbereich ist fachlich abgegrenzt, aber real genutzt. Ziel: Muster entwickeln und verifizieren.

• TQuery → TFDQuery (inkl. Parameterisierung und Typisierung)
• Transaktionsrahmen definieren und im Code sichtbar machen
• Ergebnisgleichheit nachweisen (fachlich relevante Resultsets vergleichen)
• Performance messen (Antwortzeiten, DB-Last, Netzwerkverkehr)

Am Ende des Piloten sollte eine interne Checkliste stehen, nach der jedes weitere Modul migriert wird. Das senkt Risiko und macht Aufwand planbarer.

Phase 4: Flächenmigration und Deployment-Bereinigung

Nach dem Pilot wird nach Modulen umgestellt. Parallel wird die BDE als Betriebsabhängigkeit zurückgebaut:

• Installer-Skripte und Dokumentation von BDE-Setups entfernen
• Alias-Definitionen, NetDir-Konfiguration und Sonderpfade eliminieren
• Build-/Release-Pipeline auf neue Abhängigkeiten (Client-Libs, Treiber) ausrichten

Gerade dieser Rückbau ist essenziell: Solange BDE-Teile im Deployment überleben, bleibt das Betriebsrisiko bestehen.

Stolperstellen: häufige Ursachen für fachliche Seiteneffekte

Viele Migrationen scheitern nicht an FireDAC, sondern an impliziten Annahmen im Altcode. Diese Bereiche sollten Sie früh priorisieren.

SQL-Dialekte und historisch gewachsenes SQL

BDE-Anwendungen enthalten häufig SQL, das mit einem bestimmten Treiber „zufällig“ funktionierte: implizite Joins, uneinheitliche Alias-Nutzung, DB-spezifische Funktionen, unklare Sortierungen. In der Migration gilt:

• SQL explizit machen (JOIN-Syntax statt impliziter WHERE-Verknüpfung)
• Reserved Words und Identifier prüfen (z. B. DATE, USER, ORDER als Feldnamen)
• Datums-/Zeit- und Stringfunktionen vereinheitlichen oder kapseln

FireDAC bietet Anpassungsmöglichkeiten, aber die nachhaltig richtige Lösung ist DB-konformes, gut lesbares SQL.

Datentyp-Mapping: Boolean, Datum/Zeit, Memo/Blob, NULL

Die BDE hat in der Praxis viel interpretiert. FireDAC ist präziser – was gut ist, aber Regeln verlangt. Typische Themen:

• Boolean: BIT/SMALLINT/CHAR(1) – fachlich klar definieren, keine impliziten Konvertierungen
• Datum/Zeit: DATETIME vs. DATETIME2, Millisekunden, Sortier-/Vergleichslogik; Zeitzonenfragen bei verteilten Systemen
• Memo/Blob: Fetch-Verhalten (OnDemand), Encoding, Speicherverbrauch im Client
• NULLability: Altcode, der leere Strings und NULL vermischt, führt zu schwer sichtbaren Logikfehlern

Bewährt hat sich ein schlanker Datentyp-Katalog: pro fachlich wichtiger Tabelle/Spalte Zieltypen (DB und Delphi) plus Regeln für NULL, Defaultwerte und Formatierungen.

Transaktionen: von implizit zu bewusst orchestriert

In Legacy-Delphi-Projekten ist ein häufiger Fehler, dass das System sich auf implizite Commits verlassen hat („wenn ich das Dataset schließe, ist es gespeichert“). FireDAC bietet klare APIs (StartTransaction, Commit, Rollback). Der Modernisierungsvorteil entsteht, wenn Transaktionen als fachlicher Rahmen verstanden werden:

• Use Case startet Transaktion
• Mehrere Updates laufen innerhalb derselben Connection
• Commit/Rollback erfolgt zentral mit nachvollziehbarem Error-Handling

Das reduziert Inkonsistenzen und ist entscheidend, wenn die Anwendung später um Services oder Schnittstellen ergänzt wird.

Cached Updates und Konfliktbehandlung (Concurrency)

Viele BDE-Anwendungen nutzen Cached Updates als „Offline-Edit“-Mechanik. FireDAC kann Ähnliches, aber die Regeln müssen explizit werden:

• Welche Felder sind Schlüssel, welche dienen der Concurrency-Prüfung?
• Wie werden Konflikte aufgelöst (RowVersion/Timestamp, „last write wins“, Benutzerentscheidung)?
• Was passiert bei Teilfehlern in Batch-Operationen?

In Modernisierungen ist es oft sinnvoll, die Konfliktlogik näher an die Fachlogik oder in eine Service-Schicht zu ziehen, statt sie ausschließlich im UI-Dataset-Verhalten zu verstecken.

TTable/Paradox-lastige Anwendungen: FireDAC ist nicht die einzige Baustelle

Wenn die Anwendung stark auf dateibasiertem Zugriff beruht (TTable gegen Paradox), ist „BDE durch FireDAC“ nur ein Teil der Wahrheit. FireDAC ist primär für SQL-Datenbanken gedacht. Dann ist die zentrale Entscheidung: Wird die Datenhaltung auf eine Server-DB modernisiert?

• Migration nach SQL Server, PostgreSQL oder MariaDB
• Einführung eines Rollen-/Rechtekonzepts und sauberer Backup/Restore-Prozesse
• Stabiler Mehrbenutzerbetrieb ohne Datei-Locking-Probleme

Falls ein sofortiger Datenbankwechsel organisatorisch nicht möglich ist, ist ein zweistufiges Vorgehen oft pragmatisch: erst Zugriffsschicht stabilisieren und UI-Kopplung reduzieren, dann Datenmigration mit klarer Test- und Cutover-Strategie.

Reporting, Exporte und Drittkomponenten

Reports hängen häufig an Details: Sortierungen, Filterreihenfolgen, berechnete Felder, Master/Detail-Verhalten. Für eine kontrollierte Umstellung:

• kritische Reports identifizieren und als Regressionstest-Suite behandeln
• Datensätze für Reports deterministisch erzeugen (Views/Stored Procedures oder klar definierte Queries)
• UI-seitige Filterketten reduzieren, die vom Datasetverhalten abhängen

Das Ziel ist reproduzierbare Ergebnisgleichheit, gerade bei auditrelevanten Auswertungen.

Architektur-Upgrade im Zuge der FireDAC Migration: pragmatisch entkoppeln

Die BDE-Ablösung ist ein guter Zeitpunkt, den Datenzugriff aus Formularen und Eventhandlern herauszuholen. Das bedeutet nicht, dass ein komplettes Re-Architecture-Projekt nötig ist. Schon moderate Maßnahmen bringen oft große Wirkung.

Pragmatische Zielstruktur (anschlussfähig an Layer-3-Architektur)

• Connection/Unit-of-Work: verwaltet Connection und Transaktion, stellt Query-Objekte bereit
• Repository/DAO: kapselt SQL und Datenzugriff pro fachlichem Bereich
• Service/Use Case: orchestriert Fachlogik, Validierungen und Transaktionsrahmen

Diese Struktur ist kompatibel mit einer späteren Layer-3 Architektur und erleichtert Folgeprojekte: REST-Schnittstellen, Hintergrundservices, Multiplattform-Clients oder die Kopplung an Portale.

Wichtiger Effekt: weniger globale Seiteneffekte

Viele BDE-Projekte arbeiten mit globalen Datenmodulen und impliziten Zuständen. FireDAC funktioniert auch so, aber die Modernisierung wird stabiler, wenn Zustände lokalisiert werden: klarer Lebenszyklus von Connection/Transaktion, reproduzierbare Fehlerpfade, weniger „Nebenwirkungen“ durch globalen Zustand.

Performance und Stabilität: FireDAC gezielt konfigurieren

FireDAC ist leistungsfähig, aber Performance ist eine Kombination aus SQL, Indexing, Fetch-Strategie und Connection-Management. In Migrationen zeigt sich häufig: Die BDE hat ineffiziente Muster überdeckt, weil Datenmengen früher kleiner waren oder weil das System lokal lief.

Fetch-Strategien und UI-Listen

• Listen laden nur benötigte Spalten (kein SELECT *)
• Serverseitige Sortierung und gezielte Filter statt clientseitiger Ketten
• Bei großen Datenmengen: Paging oder inkrementelles Nachladen
• LOB-Felder (Memo/Blob) erst laden, wenn wirklich benötigt

FireDAC bietet hierfür passende Optionen; entscheidend ist die fachliche Entscheidung, welche Daten ein Anwender im jeweiligen Kontext tatsächlich braucht.

Prepared Statements und Parametrisierung

Parametrisierte Queries sind nicht nur Sicherheitsstandard (SQL-Injection vermeiden), sondern verbessern in vielen Datenbanken die Plan-Wiederverwendung. Zusätzlich wird Typunsauberkeit im Altcode sichtbar und kann gezielt korrigiert werden. Gerade in gewachsenen Systemen ist das ein Qualitätsgewinn, der sich in weniger Sonderfällen und besserer Diagnostik auszahlt.

Connection-Management: Desktop vs. Service/REST

In klassischen Desktop-Clients ist oft eine langlebige Connection pro Client praktikabel. In Services oder REST-Servern sind andere Muster üblich: kurzlebigere Requests, parallele Zugriffe, Connection-Pooling. Wer die BDE-Ablösung als Teil einer größeren Modernisierung sieht, sollte diese Unterschiede im Zielbild berücksichtigen, damit spätere Ausbaustufen nicht am Datenzugriff neu beginnen müssen.

Test- und Abnahmestrategie: Ergebnisgleichheit nachweisen

Bei der BDE-Ablösung ist das Hauptrisiko selten „die Anwendung startet nicht“, sondern leise fachliche Abweichungen: Sortierungen, Rundungen, NULL-Handling, Transaktionsgrenzen, Nebenwirkungen von Triggern/Constraints in modernen DBs. Eine tragfähige Teststrategie umfasst:

• SQL-Regression: kritische Abfragen gegen definierte Testdaten ausführen und Ergebnissets vergleichen
• Use-Case-Tests: Kernprozesse (z. B. Buchen, Freigeben, Storno, Import/Export) mit Erwartungswerten prüfen
• Mehrbenutzer-/Stabilitätstests: Sperrverhalten, Deadlocks, Timeouts, Transaktionsdauer
• Logging/Observability: DB-Fehler strukturiert erfassen (Fehlercodes, Kontext, betroffene Query), nicht nur „Fehlerdialog“

Unternehmen profitieren hier doppelt: Die Tests sichern die Migration ab und schaffen eine Grundlage, um spätere Änderungen am Datenmodell oder an Schnittstellen kontrolliert auszurollen.

Zieldatenbanken in FireDAC-Projekten: typische Optionen

FireDAC ist bewusst breit, aber jede Datenbank bringt eigene Regeln. In Modernisierungen sind folgende Ziele häufig:

SQL Server

Typisch in Windows-dominierten IT-Landschaften. Wichtige Punkte: konsistente Unicode-Typen (NVARCHAR), moderne Zeittypen (DATETIME2), klare Identity-/Sequence-Strategie, definierte Isolation Levels und ein sauberer Umgang mit Sperren.

PostgreSQL

Stark bei Integrität und Features. In Migrationen relevant: Identifier-Case-Sensitivity, Datentypen (boolean/uuid/jsonb) und Dialektunterschiede. FireDAC kann PostgreSQL produktiv anbinden, wenn Client-Libraries und Deployment sauber organisiert sind.

MariaDB/MySQL

Häufig, wenn Desktopsoftware mit Web- oder Portal-Komponenten zusammenspielt. Wichtig: utf8mb4 konsequent, InnoDB als Engine, saubere Transaktions- und Indexstrategie. FireDAC unterstützt MariaDB/MySQL zuverlässig, wenn Parameter und Typen klar definiert sind.

Unabhängig vom Ziel gilt: Eine BDE-Ablösung wird am stabilsten, wenn parallel Datenbank-Standards entstehen (Schema-Versionierung, Migrationsskripte, Rollen/Rechte, Backup/Restore, Monitoring).

Praxisempfehlungen für eine planbare FireDAC Migration

Abhängigkeiten reduzieren, bevor Sie in Masse Komponenten tauschen

Wenn SQL und Dataset-Logik in vielen Formularen stecken, wird jede Änderung teuer. Ein Zwischenschritt, der SQL in wenige Zugriffsklassen bündelt, reduziert die Migrationsfläche deutlich. Danach ist die eigentliche Umstellung auf FireDAC oft schneller und risikoärmer.

Früh einen transaktionalen Kernprozess migrieren

„Einfache Listen“ sind als Einstieg bequem, aber risikoreduzierend ist es, früh einen Prozess mit echten Updates und Abhängigkeiten zu migrieren. Wenn Transaktionen, Datentypen und Fehlerpfade dort sauber sind, wird die restliche Migration planbarer.

Deployment als gleichrangige Arbeit behandeln

Die Code-Umstellung ist nur die halbe Miete. Klären Sie früh:

• Welche Client-Libraries/Treiber werden pro Datenbank benötigt?
• Wie werden diese versioniert, signiert (falls relevant) und ausgerollt?
• Wie werden Connection-Parameter verwaltet, und wer darf sie ändern?
• Wie sieht der Supportprozess aus, wenn DB-Zugriffe fehlschlagen?

FireDAC als Modernisierungsanker nutzen – ohne Neuanfang

Die Ablösung ist eine Gelegenheit für gezielte Qualitätshebel: Parametrisierung, Transaktionsgrenzen, Logging, einheitliche Fehlertexte. Das reduziert Betriebskosten und macht spätere Erweiterungen (Schnittstellen, Services) deutlich risikoärmer, ohne die Anwendung fachlich neu zu erfinden.

Fazit: BDE-Ablösung mit FireDAC ist kontrollierbare Modernisierung – wenn sie als Architekturthema behandelt wird

Die BDE hat viele Delphi-Anwendungen über Jahre getragen. Heute ist sie jedoch ein strukturelles Risiko: für 64‑Bit, für standardisiertes Deployment, für moderne Security-Anforderungen und für den Anschluss an zeitgemäße Datenbanken. FireDAC ist der passende Nachfolger, aber nicht als „Komponententausch über Nacht“. Die sichere Route ist eine schrittweise Migration mit sauberer Foundation, Pilotmodul, verbindlichen Regeln für Datentypen und Transaktionen sowie Tests, die Ergebnisgleichheit nachweisen.

Wenn Sie die BDE-Ablösung strukturiert planen möchten – inklusive Bestandsanalyse, Migrationspfad und FireDAC-Zielarchitektur – ist ein technischer Abgleich Ihrer Rahmenbedingungen der sinnvollste nächste Schritt: https://net-base-software-gmbh.de/kontakt/