Nahradit Borland BDE pomocí FireDAC: Průvodce bezpečnou modernizací Delphi bez přechodu typu Big Bang

Ve mnoha společnostech je Borland Database Engine (BDE) dodnes součástí obchodně kritických Delphi-aplikací: narostlá doménová logika, k UI blízké přístupy k datům pomocí TTable/TQuery, částečně stále Paradox/dBase, částečně rané klient/server instalace. Často platí realita: software běží, uživatelé znají procesy a v denním provozu není bezprostřední důvod „něco měnit“. Současně se mění technická základna: operační systémy se zpevňují, nasazování se standardizuje, očekává se 64‑Bit a ukládání dat by mělo probíhat na databázových serverech se seriózním konceptem práv a zálohování.

Právě v tomto bodě se z „Borland BDE durch BDE-Ablösung mit nativer Anbindung ersetzen“ stává strategický úkol modernizace. BDE-Ablosung mit nativer Anbindung je v aktuálních verzích Delphi etablovaný přístup k moderním databázím. Nabízí konzistentní chování, robustní ovladače, podporu Unicode, monitoring/tracing a architekturu, která obslouží desktopové klienty stejně jako služby a REST-servery. Přechod však zřídka znamená pouhou 1:1 výměnu komponent – obzvlášť pokud je v provozní aplikaci za léta „zapracováno“ BDE-specifické chování (předpoklady o transakcích, datové formáty, filtry/řazení, Cached Updates, reporty třetích stran).

Tento článek se soustředí na praktický postup: Jak nahradit BDE za FireDAC, aniž by byla ohrožena doménová logika a aniž by bylo třeba vynucovat Big‑Bang přechod? Získáte proveditelný model, technické cílové obrazy a upozornění na typická riziková místa v provozu podniku.

Proč je dnes BDE-ablace více než jen údržba technologie

Dokud BDE‑aplikace funguje, může se její náhrada jevit jako pouhé „uklizení kódu“. V praxi však tlak obvykle pramení z provozních a rizikových témat.

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

BDE byla historicky navržena na lokální konfiguraci (BDE Administrator, definice aliasů, NetDir, sdílené konfigurační soubory). V moderních prostředích jsou manuální kroky a systémově sdílená nastavení těžko slučitelné s distribucí softwaru, hardeningem a auditovatelností. FireDAC dovoluje výrazně lépe kontrolovaná nasazení, protože parametry připojení a nastavení ovladačů mohou být spravovány aplikaci blízko.

64‑Bit, Windows-Modernisierung und neue Plattformziele

Nejpozději když musí aplikace běžet v 64‑bitu (potřeba paměti, ekosystém ovladačů/Office, nový hardware, strategie terminálových serverů), stává se BDE v praxi překážkou. FireDAC podporuje konzistentně 32/64‑bit a je tudíž klíčovou součástí každé Delphi Modernisierung, která technicky nesmí selhat na úrovni přístupu k datům. Současně se pak témata jako Windows 11 ARM64 a hybridní klient/service architektury vůbec dají rozumně plánovat.

Datenbankstrategie: weg von dateibasiert, hin zu serverbasiert

Mnoho BDE‑aplikací nese dědictví z Paradox/dBase dob. Tyto souborové databáze jsou v multi‑uživatelském provozu náchylnější, administrativně obtížněji zálohovatelné a špatně se hodí k dnešním požadavkům (role/práva, šifrování, monitoring, vysoká dostupnost). FireDAC sice není „nový Paradox‑ovladač“, ale je moderním přístupem k SQL Serveru, PostgreSQL, MariaDB a Firebirdu. V praxi tak často BDE-ablace spouští profesionalizaci datové vrstvy a provozu.

Wartbarkeit und Diagnosefähigkeit im Betrieb

Podceňovaný náklad je diagnostika: sporadické locky, nekonzistentní chování kurzorů, těžko vysledovatelné konverze parametrů nebo síťová/cestová omezení. FireDAC poskytuje s loggingem, monitoringem a jasnějším typovým chováním lepší východiska pro reprodukovatelné analýzy chyb. Pro firmy, které aplikaci dlouhodobě provozují a občas rozšiřují, je to přímý provozní přínos.

BDE vs. FireDAC: rozdíly, které při migraci hrají roli

Na papíře lze komponenty přiřadit. V realitě jde o změny chování, které mohou mít doménové vedlejší efekty. Stručná orientace:

Komponenten-Mapping (als Startpunkt)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (v modernizacích často vhodnější: přístup založený na dotazech/views)
• TStoredProc (BDE) → TFDStoredProc

Die häufigsten Verhaltensdifferenzen

• Parametry a datové typy: FireDAC pracuje přesněji. „Už to nějak pojede“ SQL se rychleji odhalí (např. datum jako string, implicitní konverze, nejasná nullability).
• Transakce: V legacy kódu často najdete implicitní předpoklady o commitech (uzavření datasetu, vzory podobné AutoCommit, Cached Updates). U FireDAC se vyplatí vědomé řízení transakcí, protože to zlepšuje doménovou konzistenci.
• Cursor/Fetch: FireDAC má jiné výchozí hodnoty a více možností konfigurace. Neefektivní vzory (velké resultsety pro UI‑seznamy) jsou viditelnější, ale dají se cíleně optimalizovat.
• Unicode: V moderních verzích Delphi je Unicode standard. Celý řetězec FireDAC (klientská knihovna, možnosti připojení, DB‑collation, typy polí) musí být konzistentní, jinak hrozí problémy se znaky a porovnáváním.
• Deployment: V závislosti na DB jsou potřeba klientské knihovny (např. libpq pro PostgreSQL). To je třeba plánovat včas, jinak vzniknou překvapení až v produkci.

Cílový obraz pro FireDAC-architekturu: stabilní, testovatelná, rozšiřitelná

Ablace BDE by neměla skončit v „FireDAC všude nějak“. Udržitelný cílový obraz je zvláště hodnotný, pokud se má aplikace dál vyvíjet nebo být zabudována do služeb/portálů.

Minimální cíl: jednotná vrstva připojení

Místo roztroušených připojení ve formulářích doporučujeme centrální connection‑layer:

• Vytváření a konfigurace TFDConnection na jednom místě
• Jednotné time‑outy, encoding/CharacterSet, zpracování chyb
• Přepínání Dev/Test/Prod bez manuálních zásahů
• Volitelně: centrální aktivace tracingu/monitoringu pro diagnostiku

Doporučeno: jasné transakční hranice v doménové logice

Mnoho starých aplikací rozptyluje změny dat přes UI eventy. To zvyšuje riziko částečných updatů a ztěžuje testování. Stabilní přístup s FireDAC je: transakci zahajuje a ukončuje use case (služba/doménová logika), nikoli UI. I u čistě VCL desktopové aplikace vznikne tak robustní jádro, které se později snáze vystaví jako služba nebo API.

Rozšiřitelné směrem ke službám a REST

Kdo později doplní REST-server, provozuje Windows‑ nebo Linux‑služby nebo chce napojit klientský portál, těží z čisté datové vrstvy. FireDAC je pro to vhodný, pokud je při návrhu uvažováno o řízení připojení, zpracování chyb a – podle zatížení serveru – alespoň o poolování. To nemusí být zrealizováno hned v prvním kroku, ale architekturu by to nemělo blokovat.

Migrační strategie: postupné zavádění FireDAC, kontrolované odstraňování BDE

V B2B prostředích je Big Bang zřídka realistický: příliš mnoho doménových procesů, velká provozní zodpovědnost, malá akceptace delších odstávek. Postupná BDE‑ablace je obvykle bezpečná cesta.

Fáze 1: inventura stavu a mapa rizik

Užitečná inventura nekatalogizuje jen komponenty, ale hodnotí chování a vazby:

• Které databáze se používají: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Kde jsou přístupy TTable, kde se SQL používá přes TQuery, kde Stored Procedures?
• Jak se dnes s transakcemi zachází (explicitně, implicitně, Cached Updates, smíšené vzory)?
• Které reporty/exporty očekávají specifické vlastnosti datasetu (řazení, filtry, počítaná pole)?
• Které třetí komponenty nebo vlastní frameworky jsou BDE‑specifické?

Z této mapy potom vzejde rozhodnutí, zda se jedná pouze o náhradu přístupu, nebo zda je paralelně nutná migrace databáze (např. Paradox → SQL Server/PostgreSQL/MariaDB).

Fáze 2: FireDAC‑základna (bez UI změn)

Než budete migrovat obrazovky, mělo by být FireDAC technicky pevně zavedeno:

• Centrální DataModule nebo třída služby s TFDConnection
• Konfigurační model pro connection strings (např. INI/JSON) a bezpečné uchování secretů
• Standardizované zpracování chyb (převod DB‑výjimek na srozumitelné, logovatelné zprávy)
• Tracing/monitoring možnosti pro pilotní provoz (cíleně zapínatelné, ne trvale „hlučné“)

Podstatné je, aby z toho vznikly závazné standardy: konvence pojmenování, pravidla parametrů, schéma logování, výchozí nastavení pro jednotlivé DB.

Fáze 3: pilotní modul s reálnou doménovou relevancí

Dobře zvolený pilot je doménově ohraničený, ale reálně využívaný. Cíl: vyvinout a ověřit vzory.

• TQuery → TFDQuery (včetně parametrizace a typizace)
• Definovat transakční rámec a zobrazit ho v kódu
• Prokázat shodu výsledků (porovnat fachlich relevantní resultsety)
• Měřit výkon (doba odezvy, zatížení DB, síťový provoz)

Na konci pilotu by měla existovat interní kontrolní listina, podle níž se bude migrovat každé další modul. To snižuje riziko a dělá náklady plánovatelnějšími.

Fáze 4: plošná migrace a vyčištění deploymentu

Po pilotu se přepíná modul po modulu. Paralelně se BDE jako provozní závislost odstraňuje:

• Odstranit instalační skripty a dokumentaci pro BDE‑nastavení
• Eliminovat definice aliasů, NetDir konfiguraci a speciální cesty
• Upravit build/release pipeline na nové závislosti (client‑libs, ovladače)

Právě tento zpětný odbourání je zásadní: dokud části BDE přežívají v deploymentu, zůstává provozní riziko živé.

Stolperstellen: časté příčiny doménových vedlejších efektů

Mnoho migrací nezkrachuje kvůli FireDAC, ale kvůli implicitním předpokladům v starém kódu. Těmto oblastem je třeba dát prioritu brzy.

SQL dialekty a historicky vzniklé SQL

BDE‑aplikace často obsahují SQL, které s konkrétním ovladačem „náhodou“ fungovalo: implicitní joiny, nedůsledné použití aliasů, DB‑specifické funkce, nejednoznačné řazení. Při migraci platí:

• SQL dělat explicitním (JOIN syntax místo implicitních WHERE spojení)
• zkontrolovat rezervovaná slova a identifikátory (např. DATE, USER, ORDER jako názvy polí)
• sjednotit nebo zapouzdřit funkce pro datum/čas a práci s řetězci

FireDAC poskytuje možnosti přizpůsobení, ale trvale správné řešení je DB‑kompatibilní, dobře čitelné SQL.

Datový mapping: Boolean, Datum/Zeit, Memo/Blob, NULL

BDE v praxi hodně interpretovala. FireDAC je přesnější – což je výhoda, ale vyžaduje pravidla. Typické problémy:

• Boolean: BIT/SMALLINT/CHAR(1) – jasně definovat, žádné implicitní konverze
• Datum/Čas: DATETIME vs. DATETIME2, milisekundy, logika řazení/porovnávání; otázky časových pásem u distribuovaných systémů
• Memo/Blob: chování fetch (OnDemand), encoding, spotřeba paměti na klientovi
• NULLability: Starý kód, který mixuje prázdné řetězce a NULL, vede k těžko odhalitelným logickým chybám

Osvědčené je mít štíhlý katalog datových typů: pro každou doménově důležitou tabulku/sloupec cílové typy (DB a Delphi) plus pravidla pro NULL, výchozí hodnoty a formátování.

Transakce: od implicitního k vědomě orchestravanému

V legacy Delphi projektech je častá chyba spoléhat na implicitní commity („když zavřu dataset, je to uloženo“). FireDAC nabízí jasné API (StartTransaction, Commit, Rollback). Výhoda modernizace je, když jsou transakce chápány jako doménový rámec:

• Use case zahajuje transakci
• Více update probíhá v rámci téže connection
• Commit/Rollback probíhá centrálně s průkazným zpracováním chyb

To snižuje nekonzistence a je rozhodující, pokud bude aplikace později rozšířena o služby nebo rozhraní.

Cached Updates a řešení konfliktů (konkurence)

Mnoho BDE‑aplikací využívá Cached Updates jako mechanismus pro „offline editaci“. FireDAC nabízí podobné možnosti, ale pravidla musí být explicitní:

• Která pole jsou klíče, která slouží ke kontrole concurrency?
• Jak se konflikty řeší (RowVersion/Timestamp, „last write wins“, rozhodnutí uživatele)?
• Co se děje při částečných chybách v dávkových operacích?

V modernizacích často dává smysl přesunout logiku řešení konfliktů blíže k doménové logice nebo do vrstvy služeb, místo ji skrývat výhradně v UI‑dataset chování.

TTable/Paradox‑orientované aplikace: FireDAC není jediné téma

Pokud aplikace silně spoléhá na souborový přístup (TTable nad Paradox), je „BDE durch FireDAC“ jen část pravdy. FireDAC je primárně určen pro SQL databáze. Klíčové rozhodnutí tedy zní: bude se datová vrstva modernizovat na serverovou DB?

• Migrace na SQL Server, PostgreSQL nebo MariaDB
• Zavedení rolí/práv a seriózních postupů backup/restore
• Stabilní multi‑uživatelský provoz bez souborových lock problémů

Pokud okamžitá změna databáze není organizačně možná, často je pragmatické dvoufázové řešení: nejprve stabilizovat vrstvy přístupu a snížit vazby UI, poté provést datovou migraci s jasnou testovací a cutover strategií.

Reporting, exporty a třetí komponenty

Reporty často závisejí na detailech: řazení, pořadí filtrů, vypočítaná pole, master/detail chování. Pro kontrolovanou změnu:

• identifikovat kritické reporty a zacházet s nimi jako s regresní testovací sadou
• deterministicky generovat datové sady pro reporty (views/stored procedures nebo jasně definované dotazy)
• redukovat UI‑filtrační řetězce, které závisí na chování datasetu

Cílem je reprodukovatelná shoda výsledků, zejména u auditně relevantních výstupů.

Architektonický upgrade v rámci FireDAC migrace: pragmatická dekoplace

BDE‑ablace je vhodná příležitost dostat přístup k datům z formulářů a event handlerů ven. To neznamená, že je třeba kompletní re‑architektura. I mírná opatření často přinesou výrazný efekt.

Pragmatická cílová struktura (připojitelná k Layer-3‑architektuře)

• Connection/Unit‑of‑Work: spravuje připojení a transakci, poskytuje objekty Query
• Repository/DAO: zapouzdřuje SQL a přístup k datům pro jednotlivé doménové oblasti
• Service/Use Case: orchestruje doménovou logiku, validace a transakční rámec

Tato struktura je kompatibilní s pozdější Layer-3 Architektur a usnadní následné projekty: REST rozhraní, background služby, multiplatformní klienty nebo napojení na portály.

Důležitý efekt: méně globálních vedlejších efektů

Řada BDE‑projektů pracuje s globálními datamoduly a implicitními stavy. FireDAC může fungovat i tak, ale modernizace bude stabilnější, pokud jsou stavy lokalizovány: jasný životní cyklus Connection/Transakce, reprodukovatelné chybové cesty, méně „vedlejších efektů“ způsobených globálním stavem.

Výkon a stabilita: cílená konfigurace FireDAC

FireDAC je výkonný, ale výkon je kombinací SQL, indexování, fetch strategie a řízení připojení. V migracích se často ukáže, že BDE skrývala neefektivní vzory, protože objemy dat byly dříve menší nebo systém běžel lokálně.

Fetch‑strategie a UI‑seznamy

• Seznamy načítat jen potřebné sloupce (žádné SELECT *)
• Server‑side řazení a cílené filtry místo klientských řetězců
• Při velkých objemech dat: stránkování nebo inkrementální načítání
• LOB pole (Memo/Blob) načítat až v případě skutečné potřeby

FireDAC pro to nabízí vhodné možnosti; rozhodující je doménové rozhodnutí, která data uživatel v daném kontextu skutečně potřebuje.

Prepared Statements a parametrizace

Parametrizované dotazy nejsou jen bezpečnostní standard (prevence SQL‑injection), ale ve mnoha DB zlepšují opětovné použití plánů. Navíc odhalí typovou nečistotu ve starém kódu a umožní její cílenou korekci. V dlouhodobě rostlých systémech je to kvalitatívní zisk, který se projeví méně okrajovými případy a lepší diagnostikou.

Řízení připojení: Desktop vs. Service/REST

V klasických desktop klientech je často přijatelné mít trvalé připojení na klienta. V servisech nebo REST‑serverech jsou běžné jiné vzory: krátkodobé requesty, paralelní přístupy, connection‑pooling. Kdo vnímá BDE‑ablaci jako součást širší modernizace, měl by tyto rozdíly zohlednit v cílovém obrazu, aby pozdější rozšíření začínající znovu na úrovni přístupu k datům nebyla nutná.

Testovací a akceptační strategie: prokázat shodu výsledků

Při BDE‑ablaci není hlavním rizikem většinou „aplikace nespustí“, ale tiché doménové odchylky: řazení, zaokrouhlování, NULL‑handling, transakční hranice, vedlejší efekty triggerů/constraints v moderních DB. Smysluplná testovací strategie zahrnuje:

• SQL‑regrese: spuštění kritických dotazů proti definovaným testovacím datům a porovnání resultsetů
• Use‑case testy: ověření klíčových procesů (např. zaúčtování, schválení, storno, import/export) s očekávanými výsledky
• Multi‑user / stabilitní testy: chování zámků, deadlocky, time‑outy, doba transakcí
• Logging/observability: strukturované zachycení DB chyb (kódy chyb, kontext, dotaz), ne jen „chybový dialog“

Firmy z toho těží dvojnásobně: testy zajistí migraci a vytvoří základnu pro řízené nasazování pozdějších změn datového modelu nebo rozhraní.

Cílové databáze v FireDAC projektech: typické možnosti

FireDAC je záměrně široký, ale každá DB přináší vlastní pravidla. V modernizacích jsou časté následující cíle:

SQL Server

Typické v Windows‑dominovaných IT prostředích. Důležité body: konzistentní Unicode typy (NVARCHAR), moderní typy času (DATETIME2), jasná strategie Identity/Sequence, definované izolační úrovně a konzistentní práce se zámky.

PostgreSQL

Silný v integritě a funkcionalitě. Při migracích relevantní: case‑senzitivita identifikátorů, datové typy (boolean/uuid/jsonb) a dialektové rozdíly. FireDAC může PostgreSQL produktivně napojit, pokud jsou klientské knihovny a deployment dobře organizovány.

MariaDB/MySQL

Časté, pokud desktopový software spolupracuje s webovými nebo portálovými komponentami. Důležité: důsledné utf8mb4, InnoDB jako engine, čistá transakční a indexová strategie. FireDAC podporuje MariaDB/MySQL spolehlivě, pokud jsou parametry a typy jasně definovány.

Nezávisle na cíli platí: BDE‑ablace bude nejstabilnější, pokud paralelně vzniknou standardy databází (versioning schémat, migrační skripty, role/práva, backup/restore, monitoring).

Praktická doporučení pro plánovatelnou FireDAC migraci

Snižte závislosti, než budete hromadně měnit komponenty

Pokud je SQL a logika datasetu v mnoha formulářích, je každá změna nákladná. Mezikrok, který soustředí SQL do několika přístupových tříd, výrazně sníží migrační plochu. Poté je přechod na FireDAC často rychlejší a méně rizikový.

Brzy migrujte transakční jádro

„Jednoduché seznamy“ jsou jako vstup pohodlné, ale snižuje riziko migrovat včas proces, který provádí reálné updaty a má závislosti. Když budou transakce, datové typy a chybové cesty tam ošetřeny, zbytek migrace se stane plánovatelnější.

Nasazení řešte jako rovnocennou práci

Přechod kódu je jen polovina úkolu. Vyjasněte včas:

• Které klientské knihovny/ovladače budou potřeba pro jednotlivé DB?
• Jak budou tyto verze řízeny, podepisovány (pokud relevantní) a rozesílány?
• Jak budou spravovány connection parametry a kdo je bude moci měnit?
• Jak bude vypadat support proces, když DB přístupy selžou?

Využijte FireDAC jako kotevní bod modernizace – bez začátku od nuly

Ablace je příležitost pro cílené zlepšení kvality: parametrizace, transakční hranice, logging, jednotné chybové texty. To snižuje provozní náklady a činí pozdější rozšíření (rozhraní, služby) výrazně méně rizikovým, aniž by se aplikace doménově přepisovala od základu.

Závěr: BDE‑ablace s FireDAC je kontrolovatelná modernizace – pokud se k ní přistupuje jako k architektonickému tématu

BDE nesla mnoho Delphi‑aplikací léta. Dnes je ale strukturálním rizikem: pro 64‑Bit, pro standardizované nasazení, pro moderní bezpečnostní požadavky a pro napojení na současné databáze. FireDAC je vhodný následník, ale ne jako „výměna komponent přes noc“. Bezpečná cesta je postupná migrace se solidní základnou, pilotním modulem, závaznými pravidly pro datové typy a transakce a se sadou testů, které prokazují shodu výsledků.

Pokud plánujete strukturovaně BDE‑ablaci – včetně inventury, migračního plánu a FireDAC‑cílové architektury – nejrozumnějším dalším krokem je technické porovnání vašich rámcových podmínek: https://net-base-software-gmbh.de/kontakt/