A Borland BDE-t FireDAC-ra cserélni: Útmutató a biztonságos Delphi-modernizáláshoz Big Bang nélkül

Sok vállalatnál a Borland Database Engine (BDE) máig része az üzletileg kritikus Delphi-alkalmazásoknak: évek alatt felhalmozott üzleti logika, UI-közeli adatelérések TTable/TQuery használatával, részben még Paradox/dBase alapokon, részben korai kliens/szerver telepítésekkel. A gyakorlatban gyakori a helyzet: a szoftver működik, a felhasználók ismerik a folyamatokat, és a napi működésben nincs közvetlen indok „hozzányúlni”. Ugyanakkor a technikai alap megváltozik: a rendszerek megerősítése, a deployment standardizálása, a 64‑bit elvárása, valamint az, hogy az adatok adatbázis-szervereken legyenek tárolva, tiszta jogosultsági és backup-koncepcióval.

Pont ezen a ponton válik a „Borland BDE durch BDE-Ablösung mit nativer Anbindung ersetzen” stratégiai modernizációs feladattá. BDE-Ablosung mit nativer Anbindung az aktuális Delphi-verziókban a bevett adatelérési megoldás a modern adatbázisokhoz. Konzisztens viselkedést, robusztus drivereket, Unicode-támogatást, monitoring/tracing lehetőségeket és olyan architektúrát ad, amely asztali klienseket éppúgy, mint szolgáltatásokat és REST-szervereket kiszolgálhat. A váltás ritkán egyszerű 1:1 komponencsere – különösen akkor nem, ha a meglévő alkalmazás évek alatt BDE-specifikus viselkedést „beárazott” (tranzakciós feltételezések, adatformátumok, filter/sorrendek, Cached Updates, harmadik féltől származó riportok).

Ez a cikk a gyakorlati megközelítésre fókuszál: hogyan cserélje le a BDE-t FireDAC-re anélkül, hogy veszélyeztetné a szakmai logikát és anélkül, hogy Big‑Bang újraindítást kényszerítene? Konkrétan megvalósítható modellt, technikai célképeket és tipikus problématerületekre vonatkozó jelzéseket adunk az üzemi működéshez.

Miért több ma a BDE-Ablösung, mint puszta karbantartás

Amíg egy BDE-alkalmazás működik, a kicserélése pusztán „kód‑takarításnak” tűnhet. A gyakorlatban a nyomás azonban általában az üzemeltetésből és a kockázatkezelésből ered.

Deployment, Security‑Baseline és „No‑Touch” kliensek

A BDE történetileg helyi konfigurációkra épít (BDE Administrator, Alias‑definíciók, NetDir, közös konfigurációs fájlok). Modern környezetben a manuális lépések és a gépszintű beállítások nehezen egyeztethetők össze a szoftverelosztással, a megerősítéssel és az auditálhatósággal. FireDAC jóval kontrollálhatóbb deploymentet tesz lehetővé, mert a kapcsolati paraméterek és a driver‑beállítások alkalmazásközelben kezelhetők.

64‑Bit, Windows‑modernizáció és új platformcélok

Amikor egy alkalmazást 64‑biten kell futtatni (memóriaigény, driver/office ökoszisztéma, új hardver, terminalserver‑stratégiák), a BDE gyakorlatilag blokkolóvá válik. FireDAC 32/64‑bitet konzisztensen támogat, így a technikai modernizáció egyik alapköve, amely nem bukhat a adatelérés miatt. Mellékhatásként olyan kérdések, mint a Windows 11 ARM64 vagy a hibrid kliens/szolgáltatás architektúrák tervezése is kezelhetővé válnak.

Adatbázis‑stratégia: fájlalapútól a szerveralapú felé

Sok BDE-alkalmazás még Paradox/dBase‑ból származó terheket hordoz. Ezek a fájlalapú adatbázisok többfelhasználós környezetben sérülékenyebbek, adminisztratívan nehezebben menthetők, és rosszul illeszkednek a mai elvárásokhoz (szerepkörök/jogosultságok, titkosítás, monitoring, magas rendelkezésre állás). FireDAC nem egyszerűen „az új Paradox‑driver”, hanem a korszerű hozzáférés SQL Server, PostgreSQL, MariaDB és Firebird rendszerekhez. Gyakorlatilag a BDE‑kivezetés gyakran a jelzés arra, hogy az adatelhelyezést és az üzemeltetést professzionálisabbá kell tenni.

Karbantarthatóság és diagnosztika üzem közben

Alulértékelt költségtényező a hibakeresés: időszakos lock‑ok, inkonzisztens cursor‑viselkedés, nehezen nyomon követhető paraméterkonverziók vagy hálózati/útvonal problémák. FireDAC logginggal, monitoringgal és világosabb típusviselkedéssel jobb kiindulópontot ad reprodukálható hibaanalízisekhez. Azoknak a vállalatoknak, amelyek hosszabb távon üzemeltetni és pontszerűen bővíteni akarják az alkalmazást, ez közvetlen haszon.

BDE vs. FireDAC: különbségek, amelyek a migrációnál számítanak

Papíron komponensek megfeleltethetők. A valóságban viselkedésváltozások adódnak, amelyek szakmai mellékhatásokat okozhatnak. Rövid orientáció:

Komponens‑mapping (kiindulópontként)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (modernizációkban gyakran jobb: query-/view‑alapú hozzáférés)
• TStoredProc (BDE) → TFDStoredProc

A leggyakoribb viselkedéskülönbségek

• Paraméterek és adattípusok: FireDAC precízebben dolgozik. A „majd működni fog” SQL‑ek gyorsabban láthatóvá válnak (pl. dátumok stringként, implicit konverziók, bizonytalan nullability).
• Tranzakciók: A legacy kód gyakran implicit commit‑feltevésekre épít (dataset bezárása, AutoCommit‑szerű minták, Cached Updates). FireDAC esetén tudatos tranzakciókezelés javasolt, mert javítja a szakmai konzisztenciát.
• Cursor/Fetch: FireDAC más alapértékekkel és több hangolási lehetőséggel rendelkezik. Hatékonysági minták (nagy resultsetek a UI‑listákhoz) láthatóbbá válhatnak, de célzottan optimalizálhatók.
• Unicode: Az aktuális Delphi‑verziókban a Unicode alapértelmezett. A FireDAC lánc (client‑library, connection‑opciók, DB‑collation, mezőtípusok) konzisztens beállítása szükséges; különben karakter‑ és összehasonlítási problémák léphetnek fel.
• Deployment: Adatbázistól függően klienskönyvtárak szükségesek lehetnek (pl. libpq PostgreSQL‑hez). Ezt korán tervezni kell, különben üzem közeli meglepetések adódhatnak.

Célkép egy FireDAC‑architektúrához: stabil, tesztelhető, bővíthető

A BDE‑kivezetés nem vezethet „FireDAC mindenütt valahogy” állapothoz. Egy tervezett célkép különösen értékes, ha az alkalmazást továbbfejlesztik vagy szolgáltatásokba/portálokba ágyazzák.

Minimális cél: egységes Connection‑réteg

A szórt űrlapokon lévő kapcsolatok helyett ajánlott egy központi connection‑réteg:

• TFDConnection létrehozása és konfigurálása egy helyen
• Egységes timeoutok, encoding/characterSet, hibakezelés
• Dev/Test/Prod váltás manuális utómunka nélkül
• Opcionálisan: tracing/monitoring központi aktiválása diagnosztikai esetekhez

Ajánlott: világos tranzakcióhatárok a szakmai logikában

Sok régi alkalmazás adatváltoztatásokat UI‑eseményekre szétszórva kezeli. Ez növeli a részleges frissítések kockázatát és nehezíti a tesztelést. Egy stabil FireDAC‑megközelítés: a Use Case (szolgáltatás/üzleti logika) indítja és zárja a tranzakciót, nem az UI. Még tisztán VCL‑asztali szoftvernél is így kialakul egy robusztus mag, amely később könnyebben szolgáltatássá vagy API‑vá alakítható.

Bővíthetőség szolgáltatások és REST felé

Ha később REST‑szervert adnak hozzá, Windows‑ vagy Linux‑servicet üzemeltetnek, vagy egy kliensportált kötnek be, akkor egy tiszta adatréteg előnyt jelent. FireDAC alkalmas erre, ha a connection‑management, hibakezelés és – a szerver‑terheléstől függően – pooling mint célkép része a tervezésnek. Ez nem feltétlenül kell, hogy az első lépésben megvalósuljon, de az architektúrát nem szabad blokkolni.

Migrációs stratégia: FireDAC fokozatos bevezetése, BDE kontrollált leépítése

B2B környezetben a Big Bang ritkán reális: túl sok üzleti folyamat, túl nagy üzemeltetési felelősség, alacsony tolerancia hosszan tartó leállásokra. Egy lépésről lépésre történő BDE‑kivezetés általában biztonságos megoldás.

Fázis 1: állapotfelmérés és kockázattérkép

Egy használható leltár nem csak komponenseket számol, hanem viselkedést és kapcsolódásokat értékel:

• Mely adatbázis(oka)t használják: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Hol vannak TTable-hozzáférések, hol használják az SQL‑t TQuery-val, hol vannak stored procedure‑ök?
• Hogyan kezelik ma a tranzakciókat (explicit, implicit, Cached Updates, vegyes minták)?
• Mely riportok/exportok várnak bizonyos dataset‑tulajdonságokra (sorrend, filter, calculated fields)?
• Mely harmadik komponensek vagy saját frameworkök specifikusak BDE‑re?

Erről a térképről derül ki, hogy a kivezetés „csak” az elérést érinti-e, vagy párhuzamosan adatbázis‑átalakítás is szükséges (pl. Paradox → SQL Server/PostgreSQL/MariaDB).

Fázis 2: FireDAC‑foundation (UI‑átalakítás nélkül)

Mielőtt képernyőket migrálnának, FireDAC‑nek technikailag rendben kell állnia:

• Központi DataModule vagy szolgáltatás‑osztály TFDConnection-nel
• Konfigurációs modell connection stringekhez (pl. INI/JSON) és tiszta titkok kezelése
• Standardizált hibakezelés (DB‑kivételektől emberileg értelmezhető, logolható üzenetekig)
• Tracing/monitoring opciók pilotüzemhez (célzottan aktiválhatók, nem folyamatosan „hangosak”)

Fontos, hogy ezekből kötelező érvényű standardok szülessenek: névadási konvenciók, paraméterszabályok, logging‑séma, adatbázisonkénti alapbeállítások.

Fázis 3: pilotmodul valódi szakmai relevanciával

Jó pilot olyan terület legyen, amely szakmailag körülhatárolt, de valós használatban áll. Cél: minták kialakítása és ellenőrzése.

• TQuery → TFDQuery (paraméterezés és tipizálás beleértve)
• Tranzakciókeret definiálása és láthatóvá tétele a kódban
• Eredmény‑egyezőség igazolása (szakmailag releváns resultsetek összehasonlítása)
• Teljesítmény mérése (válaszidők, DB‑terhelés, hálózati forgalom)

A pilot végén legyen egy belső ellenőrzőlista, amely alapján minden további modul migrálható. Ez csökkenti a kockázatot és tervezhetőbbé teszi a ráfordítást.

Fázis 4: tömeges migráció és deployment‑tisztítás

Pilot után modulonként történik az átállás. Párhuzamosan a BDE‑t mint üzemeltetési függőséget le kell építeni:

• Installer‑scriptek és dokumentációk, amelyek BDE‑setupokat írnak le, eltávolítása
• Alias‑definíciók, NetDir‑konfiguráció és speciális elérési utak megszüntetése
• Build/release‑pipeline igazítása az új függőségekre (client‑libs, driverek)

Ez a leépítés különösen lényeges: amíg BDE‑elemek túlélnek a deploymentben, az üzemeltetési kockázat megmarad.

Stolperstellen: gyakori okok a szakmai mellékhatásokra

Sok migráció nem azért bukik meg, mert FireDAC alkalmatlan, hanem mert a régi kódban implicit feltételezések vannak. Ezeket korán kell priorizálni.

SQL‑dialektusok és történetileg összegyűlt SQL

BDE‑alkalmazásokban gyakran található olyan SQL, amely egy adott driverrel „véletlenül” működött: implicit JOIN‑ok, következetlen alias‑használat, DB‑specifikus függvények, bizonytalan rendezések. Migrációkor érdemes:

• SQL‑t explicitvé tenni (JOIN‑szintaxis az implicit WHERE‑kapcsolás helyett)
• Foglaltszavak és azonosítók ellenőrzése (pl. DATE, USER, ORDER mezőnevekként)
• Dátum/Idő és string függvények egységesítése vagy kapszulázása

FireDAC igazíthatóságot ad, de a fenntartható megoldás DB‑konform, jól olvasható SQL.

Adattípus‑térkép: Boolean, Dátum/Idő, Memo/Blob, NULL

Gyakorlatban a BDE sok mindent „értelmezett”. FireDAC precízebb – ami jó, de szabályokat követel. Tipikus kérdések:

• Boolean: BIT/SMALLINT/CHAR(1) – szakmailag egyértelműen definiálni, kerülni az implicit konverziókat
• Dátum/Idő: DATETIME vs. DATETIME2, milliszekundumok, rendezési/összehasonlítási logika; időzóna‑kérdések elosztott rendszereknél
• Memo/Blob: Fetch‑viselkedés (OnDemand), kódolás, kliens oldali memóriahasználat
• NULLability: A régi kód, amely üres stringet és NULL‑t kever, nehezen észlelhető logikai hibákhoz vezet

Bevált gyakorlat egy karcsú adattípus‑katalógus: minden szakmailag fontos táblához/oszlophoz cél‑típusok (DB és Delphi) és szabályok NULL, alapértékek és formázás tekintetében.

Tranzakciók: implicitből tudatosan orchestrált

Legacy Delphi‑projektekben gyakori hiba, hogy a rendszer implicit commitokra támaszkodott („ha bezárom a datasetet, akkor elmentődik”). FireDAC világos API‑kat kínál (StartTransaction, Commit, Rollback). A modernizáció előnye akkor jön ki, ha a tranzakciókat szakmai keretként értelmezik:

• A use case indít tranzakciót
• Több update ugyanazon connection belül fut
• Commit/Rollback központilag, nyomon követhető hibakezeléssel történik

Ez csökkenti az inkonzisztenciákat és kritikus, ha az alkalmazást később szolgáltatásokkal vagy interfészekkel egészítik ki.

Cached Updates és konfliktuskezelés (konkurencia)

Sok BDE‑alkalmazás Cached Updates‑t használ „offline szerkesztés” mechanizmusként. FireDAC képes hasonlóra, de a szabályokat explicitté kell tenni:

• Mely mezők a kulcsok, melyek szolgálnak konkurencia‑ellenőrzésre?
• Hogyan oldjuk fel a konfliktusokat (RowVersion/Timestamp, „last write wins”, felhasználói döntés)?
• Mi történik részleges hibáknál batch‑műveletek során?

Modernizációkban gyakran érdemes a konfliktuslogikát közelebb vinni az üzleti logikához vagy egy szolgáltatásrétegbe, ahelyett, hogy kizárólag a UI‑dataset viselkedésre hagyatkozunk.

TTable/Paradox‑függő alkalmazások: FireDAC nem az egyetlen teendő

Ha az alkalmazás erősen fájlalapú hozzáférésre épül (TTable Paradox ellen), akkor a „BDE durch FireDAC” csak része az igazságnak. FireDAC elsősorban SQL adatbázisokra van tervezve. A központi döntés ilyenkor: modernizálják‑e az adathordozást szerver‑DB‑re?

• Migráció SQL Serverre, PostgreSQL‑re vagy MariaDB‑re
• Szerepkör/jogosultság koncepció bevezetése és megbízható backup/restore folyamatok
• Stabil többfelhasználós üzem fájlzár‑problémák nélkül

Ha az adatbázis‑váltás szervezeti okok miatt azonnal nem lehetséges, gyakran pragmatikus a kétlépcsős megközelítés: először az elérés rétegét stabilizálni és az UI‑kötést csökkenteni, majd adat‑migrációt végrehajtani egy tiszta teszt‑ és cutover‑stratégiával.

Reporting, exportok és harmadik komponensek

A riportok gyakran részletekhez kötődnek: sorrendek, filterek sorrendje, számított mezők, master/detail viselkedés. Az ellenőrzött átálláshoz:

• kritikus riportok azonosítása és regressziós tesztcsomagként kezelése
• reportokhoz determinisztikus módon előállított adatállományok (viewk/stored procedure‑ök vagy jól definiált queryk)
• UI‑oldali filterláncok csökkentése, amelyek a dataset viselkedésére épülnek

A cél reprodukálható eredményegyezőség, különösen auditálható kimutatásoknál.

Architektúra‑upgrade a FireDAC migráció során: pragmatikusan entkoppeln

A BDE‑kivezetés jó alkalom arra, hogy az adatelérést kivonjuk az űrlapokból és eseménykezelőkből. Ez nem jelenti azt, hogy teljes újraarchitektúrát kell indítani. Már mérsékelt intézkedések is nagy hatást hozhatnak.

Pragmatikus célstruktúra (illeszthető a Layer-3‑architektúrához)

• Connection/Unit‑of‑Work: kezeli a connectiont és a tranzakciót, query‑objektumokat biztosít
• Repository/DAO: kapszulázza az SQL‑t és az adatelérést szakmai területenként
• Service/Use Case: koordinálja az üzleti logikát, validációkat és a tranzakciós keretet

Ez a struktúra kompatibilis egy későbbi Layer-3 architektúrával és megkönnyíti a következő projekteket: REST‑interfészek, háttérszolgáltatások, multiplatform kliensek vagy portálintegrációk.

Fontos hatás: kevesebb globális mellékhatás

Sok BDE‑projekt globális datamodule‑okkal és implicit állapotokkal dolgozik. FireDAC ilyen környezetben is működhet, de a modernizáció stabilabb lesz, ha az állapotok lokalizálódnak: világos élettartam a connection/tranzakció számára, reprodukálható hibapályák, kevesebb „mellékhatás” a globális állapotból.

Teljesítmény és stabilitás: FireDAC célzott konfigurálása

FireDAC nagy teljesítményre képes, de a teljesítmény SQL, indexelés, fetch‑stratégia és connection‑menedzsment kombinációja. Migrációk során gyakran kiderül: a BDE elfedte az ineffektív mintákat, mert az adatmennyiségek korábban kisebbek voltak, vagy mert a rendszer lokálisan futott.

Fetch‑stratégiák és UI‑listák

• Listák csak a szükséges oszlopokat töltsék (ne SELECT *)
• Szerveroldali rendezés és célzott szűrés a kliensoldali láncok helyett
• Nagy adatmennyiségnél: paging vagy inkrementális betöltés
• LOB‑mezőket (Memo/Blob) csak akkor töltsük, ha valóban szükséges

FireDAC megfelelő opciókat kínál; döntő a szakmai döntés arról, hogy egy adott kontextusban a felhasználónak ténylegesen mely adatok kellenek.

Prepared statements és parametrizáció

Paraméterezett queryk nem csak biztonsági standardot jelentenek (SQL‑injection elkerülése), hanem sok adatbázisban javítják a lekérdezési terv újrafelhasználhatóságát. Emellett a régi rendszer típushibáit is láthatóvá teszik és célzottan javíthatók. Egy felhalmozódott rendszerben ez minőségi javulást eredményez, kevesebb különleges esettel és jobb diagnosztikával.

Connection‑menedzsment: desktop vs. szolgáltatás/REST

Hagyományos asztali klienseknél gyakran egy hosszú életű connection per kliens praktikus. Szolgáltatásoknál vagy REST‑szervereknél más minták jellemzőek: rövidebb requestek, párhuzamos hozzáférések, connection‑pooling. Ha a BDE‑kivezetést nagyobb modernizáció részeként kezelik, ezt a különbséget a célképben figyelembe kell venni, hogy a későbbi bővítések ne az adatelérésnél kezdődjenek elölről.

Teszt‑ és átadási stratégia: eredményegyezőség bizonyítása

A BDE‑kivezetésnél a fő kockázat ritkán az, hogy „az alkalmazás nem indul el”, sokkal inkább a csendes szakmai eltérések: rendezések, kerekítések, NULL‑kezelés, tranzakcióhatárok, modern DB‑k triggereinek/konstraintjeinek mellékhatásai. Egy életképes tesztstratégia tartalmazza:

• SQL‑regresszió: kritikus lekérdezések lefuttatása definiált tesztadatokon és resultsetek összehasonlítása
• Use‑case tesztek: kulcsfolyamatok (pl. könyvelés, engedélyezés, sztornó, import/export) ellenőrzése elvárt kimenetekkel
• Többfelhasználós/stabilitási tesztek: lock‑viselkedés, deadlockok, timeoutok, tranzakciós idők
• Logging/observability: DB‑hibák strukturált rögzítése (hibakódok, kontextus, érintett query), nem csak „hibaüzenet” formájában

A vállalat kettős haszna: a tesztek biztosítják a migrációt és alapot adnak ahhoz, hogy a későbbi adatmodell‑ vagy interfészváltozásokat kontrolláltan vezessék be.

Céladatbázisok FireDAC‑projektekben: tipikus opciók

FireDAC szándékosan széles körű, de minden adatbázisnak megvannak a maga szabályai. Modernizációkban gyakori célok:

SQL Server

Tipikus Windows‑dominált IT‑környezetekben. Fontos pontok: konzisztens Unicode‑típusok (NVARCHAR), modern időtípusok (DATETIME2), egyértelmű Identity/Sequence stratégia, definiált izolációs szintek és a zárolások tiszta kezelése.

PostgreSQL

Erős integritásban és funkciókban. Migrációkhoz releváns: identifier‑case‑sensitivity, adattípusok (boolean/uuid/jsonb) és dialektusbeli különbségek. FireDAC jól kapcsolható PostgreSQL‑hez, ha a klienskönyvtárak és a deployment rendezetten vannak szervezve.

MariaDB/MySQL

Gyakori, ha az asztali szoftver webes vagy portál komponensekkel együttműködik. Fontos: utf8mb4 konzisztensen, InnoDB mint engine, tiszta tranzakciós és indexstratégia. FireDAC megbízhatóan támogatja MariaDB/MySQL‑t, ha a paraméterek és típusok világosan definiáltak.

Függetlenül a célrendszertől: egy BDE‑kivezetés a legstabilabb, ha párhuzamosan adatbázis‑standardok jönnek létre (séma‑versionálás, migrációs scriptek, szerepkörök/jogok, backup/restore, monitoring).

Gyakorlati ajánlások egy tervezhető FireDAC migrációhoz

Csökkentse a függőségeket, mielőtt tömegesen cserél

Ha az SQL és a dataset‑logika sok űrlapban szét van szórva, minden változtatás drága lesz. Egy köztes lépés, amely az SQL‑t kevés hozzáférési osztályba szervezi, jelentősen csökkenti a migrációs felületet. Ezután az átállás FireDAC‑re gyakran gyorsabb és kevésbé kockázatos.

Korán migráljon egy tranzakcionális magfolyamatot

„Egyszerű listák” kényelmesen kezdhetők, de kockázatcsökkentés szempontjából érdemes korán egy olyan folyamatot migrálni, amely valós frissítéseket és függőségeket tartalmaz. Ha ott a tranzakciók, adattípusok és hibapályák rendben vannak, a többi modul migrációja tervezhetőbb lesz.

Vegye egyenrangúnak a deploymentet

A kódátalakítás csak a munka fele. Tisztázandó korán:

• Milyen klienskönyvtárak/driverek szükségesek egyes adatbázisokhoz?
• Hogyan verzionálják és aláírják ezeket (ha releváns), és hogyan rollolják ki őket?
• Hogyan kezelik a connection‑paramétereket, és ki jogosult módosítani azokat?
• Mi a support‑folyamat, ha DB‑elérés hibába ütközik?

Használja FireDAC‑t modernizációs horgonyként – anélkül, hogy újrakezdené az egészet

A kivezetés alkalom a célzott minőségjavító lépésekre: parametrizáció, tranzakcióhatárok, logging, egységes hibaszövegek. Ez csökkenti az üzemeltetési költségeket és jelentősen csökkenti a későbbi bővítések (interfészek, szolgáltatások) kockázatát anélkül, hogy az alkalmazást szakmailag újra kellene találni.

Összegzés: BDE‑kivezetés FireDAC‑vel kontrollálható modernizáció — ha architekturális kérdésként kezelik

A BDE évekig sok Delphi‑alkalmazást kiszolgált. Ma azonban strukturális kockázatot jelent: 64‑bit, standardizált deployment, modern biztonsági követelmények és a csatlakozás korszerű adatbázisokhoz. FireDAC a megfelelő utód, de nem egy „éjszakai komponencsere”. A biztos út egy lépcsőzetes migráció tiszta foundationnel, pilotmodullal, kötelező szabályokkal adattípusokra és tranzakciókra, valamint olyan tesztekkel, amelyek bizonyítják az eredményegyezőséget.

Ha strukturáltan szeretné megtervezni a BDE‑kivezetést — beleértve a leltárt, a migrációs útvonalat és a FireDAC‑célarchitektúrát — akkor egy technikai egyeztetés az Ön keretrendszereiről a leglogikusabb következő lépés: https://net-base-software-gmbh.de/kontakt/