Paradox és BDE kontrolláltan MariaDB-re migrálni

Sok Delphi-szakalkalmazás Paradox-táblákkal és a Borland Database Engine (BDE) használatával jött létre, mert akkor ez pragmatikus szabvány volt: helyi, gyorsan üzembe helyezhető, kevés infrastruktúraigény. Gyakorlatilag ezek a rendszerek sokszor ma is élesben futnak – beleértve a riportolást, címkenyomtatást, import/exportot, kötegelt feladatokat, történeti táblákat és az az egyedi logikát, amely évek alatt „beépült” az adatelérésbe. Éppen ezért a migráció nem pusztán adatexport: kontrollált átépítés szükséges — az adatmodell, az SQL-viselkedés, a kód mellékhatásai és az üzemeltetési folyamatok együttes vizsgálatát.

A MariaDB gyakran jó választás célplatformként, ha robusztus többfelhasználós üzemre, következetes tranzakciókra, központi biztonsági mentésekre, replikációra, világos jogosultságkezelésre és webportálok, szolgáltatások vagy REST-API-k csatlakoztathatóságára van szükség. A kihívás ritkán maga az adatbázis telepítése – a tényleges munka a biztonságos migrációs úton van: hogyan viszik át helyesen a táblákat, indexeket, elsődleges kulcsokat, karakterkészleteket, dátummezőket, „üres” értékeket és a referenciális kapcsolatokat úgy, hogy a működő üzemi logika ne sérüljön?

Ez a cikk egy bevált eljárást ír le a Paradox és a BDE kontrollált MariaDB-migrációjához: műszakilag megalapozottan, lépésekre bontva és a stabilitásra fókuszálva. Cél egy terhelhető alap a további modernizációs lépésekhez – például BDE-kiváltás, átállás BDE-Ablösung mit nativer Anbindung, világos Layer-3 Architektur, REST-Server és platformfüggetlen kliensalkalmazások.

Miért több a Paradox/BDE-migráció, mint egy adatbáziscsere

A Paradox fájlformátum és a BDE mint hozzáférési réteg egy olyan rendszert alkotnak, amelynek sajátosságait nem érdemes 1:1 módon „visszaépíteni” MariaDB-ben. A napi üzem során tipikus tünetek:

• Átláthatatlan függőségek: SQL-utasítások szétszórtan találhatók (űrlapok, DataModule-ök, riportok, dinamikus String-SQL), gyakran központi irányítás nélkül.
• „Megérzés szerinti“ viselkedés: Egyes szűrők, rendezések vagy join-ok véletlenszerűen működnek, mert Paradox/BDE toleráns vagy implicit típuskonverziót végez.
• Többfelhasználós korlátok: Fájlalapú zárolások, hálózati teljesítménycsökkenés, zárolási problémák növekvő adatmennyiség mellett.
• Karbantartási kockázatok: BDE-függőségek, régi driverek, nehéz deployment modern Windows-verziókra, 64‑bit/ARM64 kérdések.

Eine kontrollált migráció ezeket a pontokat nem mellékhatásként kezeli, hanem célkényszerként. A MariaDB nem csupán „új adatbázis“ lesz, hanem lehetőség az adatelérési réteg leválasztására, a szakmai integritás növelésére és az integrációs képességek megteremtésére.

Célkép: MariaDB mint stabil adatalap desktophoz, szolgáltatásokhoz és portálokhoz

Egy ésszerű célkép B2B szakalkalmazásokhoz általában három rétegből áll:

• Adatbázis (MariaDB): konzisztens adattárolás, indexek, constraintek, tranzakciók, felhasználók/rolok, biztonsági mentések.
• Szaklogika (Server/Services): validációk, munkafolyamatok, importerek, scheduler, interfészek. Opcionálisan mint REST-Server, Windows- vagy Linux-Services.
• Kliensoldal (VCL/FMX/Web): kezelőfelületek, riportok, offline részek, integrációk. Ideálisan világos szerződésekkel a szaklogikára nézve.

A kiindulási állapottól függően nem kell mindent egyszerre megvalósítani. A migrációt azonban úgy kell tervezni, hogy ne zárja el a tiszta architektúra felé vezető utat. Aki ma csak táblákat másol és holnap ismét „közvetlenül“ minden űrlapról az adatbázisra ír, bevezeti ugyan a MariaDB-t, de a valódi kockázatok megmaradnak.

Felvételezés: mi az, amit ténylegesen migrálni kell

A kezdeti lépés egy leltár készítése, amely túlmutat a „hány tábla van“ kérdésen. Paradox/BDE-projektekben tipikus, hogy az adatbázis csak egy része az igazságnak. Fontos pontok:

1) Táblák, indexek, „pszeudo-kulcsok”

Gyakran hiányoznak az igazi PRIMARY KEY-ek. Helyettük mezők kombinációi, egyedi constraint nélküli sorszámok vagy az alkalmazás által karbantartott „kulcs” mezők léteznek. MariaDB-ben ezekből megbízható, egyértelmű kulcsokat kell képezni — különben a tranzakciók és a referenciális integritás csak korlátozottan működnek.

2) Lekérdezések, dinamikus SQL-építők, riportok

BDE komponensenként eltérő SQL-dialektust használhat és tolerálhat „kreatív“ utasításokat. A riportkomponensek (még az öregebbek is) gyakran saját SQL-definíciókat tartalmaznak. A migrációnak ezeket a forrásokat fel kell tárnia és kategorizálnia: kritikus mag-lekérdezések, ritkán használt kimutatások, speciális importok.

3) Karakterkészlet és különleges karakterek (umlautos betűk, ISO/ANSI, Unicode)

Sok Paradox-alkalmazás történetileg ANSI-alapú. Ha a Delphi-alkalmazás maga később Unicode-ra állt át, keveredő világok jöhetnek létre: adatok régi kódolásban, UI Unicode, exportok Windows-1252-őt várnak. A MariaDB-nek itt tiszta koncepciót kell kapnia (jellemzően utf8mb4), beleértve a gondos konverziót és teszteket az „láthatatlan” hibákra (összehasonlítások, rendezés, Trim/Pad, különleges karakterek).

4) „Üres“ értékek, NULL-logika és dátummezők

A Paradox/BDE különféle különleges eseteket ismer: üres stringek NULL helyett, 0-értékű dátumok, „üres” időbélyegek, alapértelmezett értékek, amelyek a felületen jönnek létre. A MariaDB szigorúan megkülönbözteti a NULL-t és az üreset. Ez befolyásolja a WHERE-klauszulákat, aggregációkat és számításokat. Ezeket a különbségeket táblánként/mezőnként kell értékelni.

5) Mellékes artefaktumok: session-táblák, lokális konfiguráció, cache

Gyakran találhatók Paradox-szerkezetben lokális táblák köztes eredményekhez, export-pufferhez, felhasználói elrendezésekhez vagy paraméterekhez. Egy részük maradhat lokális (például UI-elrendezések), másokat központosítani kell (pl. munkafolyamatok, állapotok, naplók). A migráció alkalom a kategóriák tiszta szétválasztására.

Bukkanók Paradox/BDE esetén: tipikus műszaki különbségek

Ahhoz, hogy a migráció tervezhető legyen, érdemes a visszatérő különbségeket kifejezetten kezelni.

SQL-dialektus és operátorok

BDE/Paradox-SQL nem azonos a MySQL/MariaDB-SQL-lel. Különbségek lépnek fel többek között dátumfüggvényeknél, string-függvényeknél, külső joinoknál (historikusan), Like/maszkműködésnél és az implicit típuskonverziókban. Egy kontrollált megközelítés „működik már“ helyett világos szabályokat alkalmaz: mely utasításokat portoljuk, melyeket írunk újra, és melyeket kapszulázunk nézetekbe vagy tárolt eljárásokba, ha az értelmes?

Rendezés és collation

Paradoxban a rendezési sorrend és a kis-/nagybetű-érzékenység gyakran eltér MariaDB-től, különösen az umlautoknál. MariaDB-ben a collation (pl. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) határozza meg az összehasonlítás és rendezés viselkedését. Ez nem elméleti kérdés: hatással van a deduplikációra, keresési funkciókra és az egyedi constraintek működésére.

Autoincrement és számozási körök

Paradox rendelkezik autoincrement-mezőkkel, de az alkalmazások gyakran saját számozási köröket használnak (számla-, rendelési számok) speciális logikával. MariaDB-ben világosan el kell választani:

• Technikai elsődleges kulcs: AUTO_INCREMENT (vagy UUID, az architektúrától függően) a relációkhoz.
• Szakmai szám: külön számozási kör tranzakciós védelemmel, szükség esetén ügyfétenként/időszakonként.

Aki egy szakmai számot technikai kulcsként próbál megfordítani, később drága átalakításokra számíthat.

Zárolás és tranzakciók

A váltás a fájlalapú hozzáférésről egy valódi szerverre nyereség, de megváltoztatja a viselkedést. MariaDB-ben a tranzakciók (InnoDB) alapvetőek. Dönteni kell, hol legyenek a tranzakciós határok: per párbeszéd, per mentésművelet, per köteg. Különösen fontos: hosszú tranzakciók és percig tartó „szerkesztési módok“ gyakoriak Paradox-világokban, de szerveroldalon problémásak (zárolások, deadlockok, replikációs késések). Itt gyakran az üzemmód vagy az UI módosítása is a migráció részét képezi.

Módszer: kontrollált migráció ütemekben, nem Big Bang

B2B környezetben az üzem-stabilitás gyakran fontosabb, mint az egykori gyorsvágás. Egy lépésenkénti migrációs útvonal csökkenti a kockázatot, mert a szakmai terület és az IT iteratívan validálhat.

Etap 1: Adatmodell-átvitel mappinggal, kódátalakítás nélkül

Az első lépésben felépül egy MariaDB-séma, amely leképezi a Paradox-struktúrát – de már a célelvekkel: PRIMARY KEY-ek, indexek, megfelelő adattípusok, utf8mb4, InnoDB. Párhuzamosan reprodukálható importfolyamat készül (szkriptek/eszközök), amely szükség esetén megismételhető. Fontos a reprodukálhatóság, mert a migráció sosem kész el az első futásra.

Ennek az etapnak a deliverable-jei tipikusan:

• Verzionált séma-definíció (DDL) (pl. Gitben)
• Mezőmapping-lista (Paradox → MariaDB) konverziós szabályokkal
• Import-eljárás naplózással (rekordszámok, hibák, kiugró értékek)
• Első validációs riportok (számlálás, összegek, ellenőrzőösszegek)

Etap 2: BDE-kiváltás az adatelérésben (pl. FireDAC használatával)

A valódi modernizációs lépés a BDE leválasztása. Delphi-projektekben a BDE-Ablosung mit nativer Anbindung bevált megoldás, mert modern drivereket, tranzakciókezelést, paraméterkötést és egységes komponenseket ad különböző SQL-backendekhez. A döntő kérdés nem az, hogy „kikerüljön-e a BDE“, hanem az, hogy utána hogyan néz ki a kód: központosított adatelérés, világos hibakezelés, tiszta paraméterezés a string-konkatenáció helyett.

Tipikus feladatok ebben az etapban:

• TTable/TQuery cseréje FireDAC-Querykre és DataSet-ekre
• Adatelérési réteg (DAL) bevezetése, alapként a későbbi Layer-3 architektúrához
• Tranzakció-scope-ok standardizálása (Commit/Rollback)
• SQL-átvizsgálat: dialektusigazítás, paraméterek, lapozás, join-ok

Ha az alkalmazás hosszú távon modernizálandó, ez a lépés gyakran fontosabb, mint az egyszerű adatátvitel. Megteremti a technikai szabadságot 64‑bit, modern Windows-verziók és tiszta deployment-pipeline-ok számára.

Etap 3: Párhuzamos üzem és szakmai átvétel üzemszünet nélkül

Kritikus rendszerek esetén érdemes párhuzamos üzemet alkalmazni: a MariaDB felépül és ciklikusan (vagy inkrementálisan) töltődik, miközben a régi rendszer tovább működik. Így a szakmai terület össze tudja hasonlítani a kimutatásokat, azonosítani a szélsőséges eseteket és terhelés alatt tesztelni az új platformot. A párhuzamos üzem különböző módokon valósítható meg:

• Read-only replik riporting/BI-előkészítéshez
• „Dual Write” meghatározott részterületeken (csak jól kontrollált esetben)
• Stichtag-szerinti migráció több próbafutással és világos cutover-checklistával

Fontos, hogy ne bonyolítsuk túl a végrehajtást: a Dual-Write vonzónak tűnik, de hibára hajlamos, ha a szaklogika nincs központosítva. Gyakran a megismételhető stichtag-futtatás jó validációval gazdaságosabb.

Etap 4: Optimalizálás, integritás, teljesítmény, üzemeltetési folyamatok

A cutover után kezdődik az a fázis, ahol a MariaDB erősségeit ki kell használni: referenciális integritás, hatékony indexek, tiszta jogosultságok, monitoring, backup/restore tesztek. Itt szoknak megjelenni az „igazi“ terhelések: hosszú riportok, rosszul indexelt keresők, kötegelt frissítések. Egy kontrollált migráció explicit módon tervezi be ezt az etapát, ahelyett, hogy későbbi nem tervezett utánmunkaként keletkezne.

Adattípusok és mapping: Paradox → MariaDB információvesztés nélkül

A mezőmapping a migráció szíve. Tipikus hozzárendelések (egyszerűsítve):

• Alpha / Memo: VARCHAR/TEXT (utf8mb4), hosszellenőrzés és trim-szabályok
• Number: INT/BIGINT/DECIMAL a tartománynak megfelelően; óvatosság az implicit tizedeseknél
• Date/Time: DATE/DATETIME/TIMESTAMP; világos szabályok a „0-dátum“ vagy NULL kezelésére
• Logical: BOOLEAN vagy TINYINT(1) egyértelmű szemantikával
• Currency: DECIMAL(…,2/4) Float helyett a kerekítési hibák elkerülésére

Fontos nem csak az adattípusok fordítása, hanem a szakmai szabályok rögzítése is: Egy mező lehet-e NULL? Melyek a helyes default értékek? Mely mezőkombinációknak kell egyedinek lenniük? Ezekből adódnak a constraintek és indexek. Ezek a szabályok Paradox/BDE-rendszerekben gyakran implicit módon a UI-ban vagy a kódban voltak elrejtve — MariaDB-ben, ahol értelmes, explicitté kell tenni őket.

Integritás: PRIMARY KEY-ek, FOREIGN KEY-ek és egyedi indexek

Sok legacy-adatbázis évekig működik referenciális integritás nélkül – amíg integrációk, portálok vagy párhuzamos folyamatok meg nem jelennek. Ekkor az adathigiénia válik szűk keresztmetszetté. MariaDB-ben Foreign Key-ek, Unique Constraintek és Checks (verziótól/engine-től függően) bevezethetők, hogy az adathibákat korán elkapjuk.

Gyakorlatias megközelítés az integritás fokozatos bevezetése:

• Először PRIMARY KEY-ek és egyedi indexek a kulcsobjektumokra (vevők, cikkek, bizonylatok)
• Azután FOREIGN KEY-ek a stabil területeken
• „Történeti“ táblák esetén: először tisztítás, aztán constraintek

Ez csökkenti annak kockázatát, hogy a cutover a régi adathibák miatt meghiúsuljon, miközben jelentősen javítja az általános állapotot.

Teljesítmény a gyakorlatban: mi változik MariaDB-vel

A Paradox/BDE-rendszerek gyakran „fájlszerű gyorsaságra“ optimalizáltak: helyi indexek, gyors táblahozzáférés, sok kliensoldali szűrés. MariaDB-vel a munka a szerverre tolódik. Ez előny, de megköveteli a tiszta SQL- és indexstratégiát.

Típikus teljesítménybuktatók

• SELECT * nagy táblákból, mert korábban „helyben“ elég gyors volt
• Kliensoldali szűrés a szerveroldali WHERE helyett
• Hiányzó összetett indexek keresőmező-összetételeken (pl. mandant + státusz + dátum)
• LIKE ‚%text%‘ megfelelő teljes szövegű stratégia nélkül

Mérhető javítások „érzés“ helyett

Egy kontrollált migráció korán bevezet mérőpontokat: Slow Query Log, EXPLAIN-analízisek, reprodukálható terheléses tesztek. Különösen fontos ez, ha a migráció után további komponensek jönnek, például egy REST-Server vagy egy Kundenportal, amely újabb hozzáférési mintákat eredményez (sok kis kérés, lapozás, keresővégpontok).

Delphi-specifikus: BDE-kiváltás, FireDAC és tiszta adatelérési rétegek

Delphi-projektekben a technikai modernizáció szorosan összefügg az adateléréssel. A BDE nem csupán „egy driver“, hanem egy teljes hozzáférési stílus (TTable, rekordalapú, navigálás, lokális szűrők). A MariaDB-re való migráció jó alkalom a hozzáférés konszolidálására.

DataSet-ek mindenütt → kontrollált adatelérés

Sok alkalmazás minden űrlapban saját lekérdezéseket tartalmaz. Ez rosszul skálázódik szakmailag és biztonságilag. Bevált irány:

• Központi repository-/service-osztályok a kulcsobjektumokhoz
• Egységes hibakezelés és tranzakciókezelés
• Paraméterezett lekérdezések (SQL-injekció elkerülése, plan-caching kihasználása)
• Konfigurálható connection-poolok vagy connection-management szolgáltatásokhoz

Ez alapot ad egy Layer-3 architektúrának, ahol az UI, a szaklogika és a perzisztencia tisztán szétválnak. Ez nemcsak az adatbázisváltásnál segít, hanem későbbi bővítéseknél is, például REST-szerver vagy háttérszolgáltatások felé.

MariaDB-csatlakozás FireDAC-pel: tipikus tisztázandók

Projektekben ismétlődően felmerülnek ugyanazok a kérdések: melyik driver-variáns (MySQL/MariaDB), milyen SSL-opciók, mely Timezone- és dátumbeállítások, milyen Unicode-beállítások? Ezek nem apróságok, mert közvetlen hatásuk van az adatkonszisztenciára (időpontok), rendezésre és az üzembiztonságra (TLS). Egy kontrollált migráció ezeket a paramétereket rögzíti, dokumentálja és valós adatokkal teszteli.

Cutover-terv: vágónap, adatzárolás, visszaállítás – meglepetések nélkül

A cutover maga egy projekt. Egy jó cutover-terv nem csupán azt írja le, „mikor állítunk át“, hanem a védőintézkedéseket is:

• Adatzárolás: Mikortól nem rögzítenek több adatot a régi rendszerben? Vannak-e vészfolyamatok?
• Végső import: Mennyi ideig tart reálisan? (Próbafutások adnak számokat.)
• Validáció: Milyen ellenőrzéseknek kell zöldnek lenni átadás előtt (számlálások, összegek, mintavétel, szakmai riportok)?
• Visszaállítás: Mikor szakítjuk meg, és milyen lépések következnek?
• Kommunikáció: Ki ad engedélyt? Ki elérhető a War Room-ban?

Középvállalati környezetben a „rollback“ gyakran nem technikai, hanem szervezeti kihívás. Ezért a migrációt úgy kell előkészíteni, hogy a cutover ne kísérlet, hanem egy begyakorolt művelet legyen.

Az átállás után: alap REST-hez, szolgáltatásokhoz és multiplatformhoz

Ha a MariaDB stabilan működik és a BDE-kiváltás tisztán megtörtént, új opciók nyílnak: REST-API-k külső rendszerekhez, háttérfeldolgozás mint Windows- vagy Linux-services, a UI és a szaklogika leválasztása, valamint perspektivikusan multiplatform kliensalkalmazások. Gyakori következő lépés a szaklogika kivétele a desktopból, hogy integrációkat (ERP/DMS/CRM) és portálokat kontrolláltan lehessen kiszolgálni.

Fontos: egy REST-Server nem pusztán „plusz réteg“, hanem architekturális döntés. Aki már szolgáltatásokban/repository-kban konszolidálta az adatelérést, validálást és jogosultságokat, sokkal könnyebben fejleszthet robusztus API-kat.

Gyakorlat – ellenőrzőlista: mit tisztázzanak a projektindítás előtt

• Mely modulok kritikusak az üzlet számára és a cutover napján biztosan működniük kell?
• Mekkora a valós adatmennyiség (táblaméretek, növekedés, archiválási koncepció)?
• Mely riportoknak kell 1:1-ben megegyezniük, és melyek fejleszthetők?
• Milyen integrációk függnek a rendszertől (fájlexportok, ODBC, Office, nyomtatási folyamatok)?
• Van-e többbérlős működés (Mandantenfähigkeit), és ha igen: hogyan van ábrázolva ma?
• Milyen üzemeltetési követelmények érvényesek (backup-ablak, restore-idő, jogok, audit)?

Ezek a tisztázások nem bürokrácia: megakadályozzák, hogy a migráció technikailag „kész“ legyen, de szakmailag ne legyen átvehető.

Összegzés: Kontrollált migráció = kockázatok tervezhetővé tétele

A Paradox és a BDE kontrollált MariaDB-re való migrációja azt jelenti, hogy az alkalmazást rendszerszinten modernizáljuk: adatmodell, SQL, tranzakciók, karakterkészlet, hozzáférési réteg és üzemeltetési folyamatok. Aki a váltást pusztán adatexportnak tekinti, gyakran ugyanazokat a problémákat kapja vissza — most egy új szerveren.

Az iteratív megközelítés reprodukálható importtal, gondos mezőmappinggal, korai validálással és egy világos BDE-kiváltással (pl. FireDAC) ehelyett stabil alapot teremt: többfelhasználós üzemhez, integrációkhoz, szolgáltatásokhoz és a következő modernizációs lépésekhez, például a Delphi Modernisierung.

Ha a migrációt szakmailag biztonságosan és üzemszünet nélkül szeretnék végrehajtani, szívesen áttekintjük a kiinduló állapotot, a kockázatokat és egy reális etaptervet: https://net-base-software-gmbh.de/kontakt/