Paradox in BDE nadzorovano migrirati v MariaDB

Veliko Delphi-strokovnih aplikacij je nastalo z uporabo Paradox-tabel in Borland Database Engine (BDE), ker je bila takrat praktična izbira: lokalno, hitro pripravljeno za zagon, z malo infrastrukture. V praksi ti sistemi pogosto delujejo v produkciji še danes – vključno z izpisi poročil, tiskom etiket, uvozom/izvozom, paketnimi opravili, zgodovinskimi tabelami in posebno logiko, ki se je skozi leta „vdelala“ v dostop do podatkov. Ravno zato migracija ni le izvoz podatkov, temveč kontrolirana preureditev: podatkovni model, vedenje SQL, stranski učinki v kodi in obratovalni procesi morajo biti obravnavani skupaj.

MariaDB je pogosto zelo dobra ciljna platforma, kadar gre za robustno večuporabniško delovanje, urejene transakcije, centralne varnostne kopije, replikacijo, jasno upravljanje pravic in priključljivost za spletna portala, storitve ali REST-API-je. Izziv redko predstavljajo same namestitve baze – pravi napor je v varni migracijski poti: kako pravilno prenesti tabele, indekse, primarne ključe, nabor znakov, datumska polja, »prazne« vrednosti in referenčne povezave, ne da bi se poslovna logika med obratovanjem zlomila?

Ta prispevek opisuje uveljavljeno postopanje za kontrolirano migracijo Paradox in BDE na MariaDB: tehnično utemeljeno, fazno in s poudarkom na stabilnosti. Cilj je vzdržna osnova za nadaljnje modernizacijske korake – na primer BDE-odstranitev, prehod na BDE-Ablösung mit nativer Anbindung, jasna Layer-3 Architektur, REST-Server in platformno združljivi odjemalci.

Zakaj je migracija Paradox/BDE več kot le zamenjava baze

Paradox kot datotečni format in BDE kot sloj za dostop tvorita celovit sistem z lastnostmi, ki jih v MariaDB ni smiselno 1:1 »posnemati«. Tipični simptomi v vsakdanjem delu so:

• Nepregledne odvisnosti: SQL-izjave so razpršene (Forms, DataModules, Reports, dinamični String-SQL), pogosto brez osrednje governance.
• Vedenje »po občutku«: Določeni filtri, razvrstitve ali joini delujejo naključno, ker je Paradox/BDE toleranten ali implicitno pretvarja tipe.
• Meje večuporabniškega delovanja: Zaklepanja na datotečni ravni, upad zmogljivosti v omrežju, težave z blokiranjem ob rasti količine podatkov.
• Tveganja vzdrževanja: Odvisnosti od BDE, stari gonilniki, zahtevno nameščanje na sodobnih Windows-verzijah, 64‑Bit/ARM64 vprašanja.

Kontrolirana migracija teh točk ne obravnava kot stranske učinke, temveč kot merila uspeha. MariaDB pri tem ni le »nova baza«, ampak priložnost za razvezavo sloja za dostop do podatkov, povečanje strokovne integritete in vzpostavitev vmesnikov.

Ciljno stanje: MariaDB kot stabilna podatkovna osnova za namizje, storitve in portale

Smiselno ciljano stanje za B2B-strokovne aplikacije običajno sestavljajo tri plasti:

• Baza podatkov (MariaDB): konsistentno hranjenje podatkov, indeksi, omejitve, transakcije, uporabniki/role, varnostne kopije.
• Strokovna logika (Server/Services): validacije, poteki dela, uvozniki, razporejevalnik, vmesniki. Opcijsko kot REST-Server, Windows- ali Linux-Services.
• Odjemalci (VCL/FMX/Web): uporabniški vmesniki, poročila, offline deli, integracije. Idealno s jasnimi pogodbami glede strokovne logike.

Glede na izhodišče ni treba vsega uresničiti takoj. A migracija naj bo načrtovana tako, da ne zapre poti do čiste arhitekture. Kdor danes samo kopira tabele in jutri zopet »direktno« iz vsakega obrazca piše v bazo, je sicer uvedel MariaDB, vendar ostajajo dejanska tveganja nespremenjena.

Inventura: Kaj je res treba migrirati

Na začetku stoji inventura, ki presega vprašanje »koliko tabel«. V Paradox/BDE-projektih je običajno, da je baza le del resnice. Pomembne točke:

1) Tabele, indeksi, »pseudo-ključi«

Pogosto manjkajo pravi primarni ključi. Namesto tega obstajajo kombinacije polj, tekoče številke brez eksplicitne omejitve ali »key« polja, ki jih upravlja aplikacija. V MariaDB morajo iz tega nastati enolični, zanesljivi ključi – sicer so transakcije in referenčna integriteta le omejeno učinkoviti.

2) Poizvedbe, dinamični SQL-izseki, poročila

BDE uporablja glede na komponento različne SQL-dialekte in dopušča »kreativne« izjave. Komponente za poročanje (tudi starejše) pogosto vsebujejo lastne SQL-definicije. Migracija mora najti in kategorizirati te vire: kritične osrednje poizvedbe, redko uporabljene analize, specialni uvozi.

3) Nabor znakov in posebni znaki (Umlauti, ISO/ANSI, Unicode)

Številne Paradox-aplikacije so zgodovinsko ANSI-bazirane. Če je bila Delphi-aplikacija sama kdaj preklopila na Unicode, nastanejo mešane situacije: podatki so v starem kodiranju, uporabniški vmesnik je Unicode, izvozi pa pričakujejo Windows-1252. MariaDB bi morala imeti jasen koncept (tipično utf8mb4), vključno s kakovostno konverzijo in testi na »nevidne« napake (primerjave, razvrščanje, Trim/Pad, posebni znaki).

4) »Prazne« vrednosti, logika NULL in datumska polja

Paradox/BDE pozna različne posebne primere: prazni nizi namesto NULL, 0-podatki, »prazni« časovni žigi, privzete vrednosti, ki nastanejo v UI. MariaDB striktno razlikuje med NULL in praznim nizom. To vpliva na WHERE-pogoje, agregacije in izračune. Te razlike je treba za vsako tabelo/polje oceniti posebej.

5) Stranski artefakti: sejne tabele, lokalna konfiguracija, predpomnilnik

Pogosto so v Paradox-strukturi lokalne tabele za vmesne rezultate, izvozne medpomnilnike, uporabniške postavitve ali parametre. Nekaj je smiselno ostati lokalno (npr. UI-postavitve), drugo pa bi moralo biti centralno (npr. delovni procesi, statusi, dnevniki). Migracija je priložnost, da te kategorije jasno ločimo.

Polena na poti Paradox/BDE: tipične tehnične razlike

Za planiranje migracije se izplača eksplicitno nasloviti ponavljajoče se razlike.

SQL-dialekt in operatorji

BDE/Paradox-SQL ni identičen MySQL/MariaDB-SQL. Razlike se pojavijo npr. pri datumskih funkcijah, funkcijah za nize, outer joinih (zgodovinsko), logiki Like/maske in pri implicitnih pretvorbah tipov. Kontroliran pristop nadomesti »deluje že« z jasnimi pravili: katere izjave se portirajo, katere se zavestno prepišejo, katere se zapakirajo v Views/Stored Procedures (če ima to smisel)?

Razvrščanje in collation

V Paradoxu so razvrstitve in občutljivost na velike/male črke pogosto drugačne kot v MariaDB, posebej pri umlautih. V MariaDB collation (npr. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) določa primerjave in razvrščanje. To ni akademsko vprašanje: vpliva na deduplikacijo, funkcije iskanja in vedenje Unique-omejitev.

Autoincrement in številčni krogi

Paradox ima polja z avtoinkrementom, vendar aplikacije pogosto uporabljajo lastne številčne kroge (številke dokumentov, številke naročil) s posebno logiko. V MariaDB je treba jasno ločiti:

• Tehnični primarni ključ: AUTO_INCREMENT (ali UUID, glede na arhitekturo) za relacije.
• Funkcijska številka: lasten številčni krog z zaščito tranzakcij, po potrebi na ravni mandanta/perioda.

Kdor poskuša funkcijsko številko zlorabiti kot tehnični ključ, si kasneje nakoplje drage preureditve.

Zaklepi in transakcije

Prehod iz datotečnega dostopa na pravi strežnik je pridobitev, vendar spremeni vedenje. V MariaDB so transakcije (InnoDB) centralne. Treba se je odločiti, kje potekajo meje transakcij: na nivoju dialoga, na nivoju shranjevanja, na nivoju paketnega opravila. Posebej pomembno: dolge transakcije in urejen »Edit-Mode« trajajo v Paradox-svetovih minute, a so na strežniški strani problematične (zaklepi, deadlocki, replikacijski zamik). Tukaj je prilagoditev delovnih načinov ali UI pogosto del migracije.

Postopek: kontrolirana migracija v fazah namesto Big Bang

V B2B-okoljih je stabilnost obratovanja pogosto pomembnejša od hitrega reza. Fazen migracijski pot zmanjšuje tveganje, ker poslovne enote in IT iterativno validirajo.

Faza 1: Prenos podatkovnega modela z mapiranjem, brez preurejanja kode

V prvem koraku se vzpostavi MariaDB-shema, ki prikazuje Paradox-strukturo – vendar že z ciljnih načel: primarni ključi, indeksi, smiselne tipne izbire, utf8mb4, InnoDB. Vzporedno se ustvari reproducibilni postopek uvoza (skripte/oprava), ki ga je mogoče po potrebi ponoviti. Pomembna je ponovljivost, ker migracija nikoli ni dokončna po prvem teku.

Izvedljivi rezultati te faze so običajno:

• Definicija sheme (DDL) verzionirana (npr. v Git)
• Seznam mapiranja polj (Paradox → MariaDB) vključno s pravili konverzije
• Postopek uvoza z beleženjem (število zapisov, napake, odstopanja)
• Prva validacijska poročila (štetja, vsote, kontrolne vsote)

Faza 2: BDE-odstranitev v dostopu do podatkov (npr. z FireDAC)

Pravi modernizacijski korak je razvezava od BDE. V Delphi-projektih je BDE-Ablosung mit nativer Anbindung preizkušen pristop, ker prinaša moderne gonilnike, transakcije, vezavo parametrov in enotne komponente za različne SQL-backende. Ključno ni „BDE ven“, temveč kako bo koda izgledala potem: centralni dostop do podatkov, jasna obdelava napak, čisti parametri namesto konkatenacije nizov.

Tipične naloge v tej fazi:

• Zamenjava TTable/TQuery z FireDAC-Queryji in DataSeti
• Uvedba sloja za dostop do podatkov (DAL) kot osnova za poznejšo Layer-3 arhitekturo
• Standardizacija transakcijskih obsegov (Commit/Rollback)
• Pregled SQL: prilagoditev dialekta, parametri, paginacija, joini

Če naj vaša aplikacija dolgoročno modernizira, je ta korak pogosto pomembnejši od čiste podatkovne migracije. Ustvari tehnično svobodo za 64‑Bit, sodobne Windows-verzije in čiste deployment-pipepline.

Faza 3: Paralelno obratovanje in strokovna prevzemljivost brez prekinitve delovanja

Za kritične sisteme je smiselno vzpostaviti paralelno obratovanje: MariaDB se na zagonu polni ciklično (ali inkrementalno), medtem ko stari sistem še deluje. Tako lahko strokovne oddelke primerjajo izpise, identificirajo robne primere in testirajo novo platformo pod obremenitvijo. Paralelno delovanje je mogoče uresničiti na več načinov:

• Read-only replik za pripravo poročanja/BI
• »Dual Write« v definiranih delih (samo, če je dobro obvladano)
• Stiki prehod z več sušilnimi teki in jasno kontrolno listo za preklop

Pomebno je, da ne kompliciramo preveč: Dual-Write se sliši privlačno, a je nagnjen k napakam, če poslovna logika ni centralizirana. Pogosto je ponovljiv enokraten prehod ob dogovorjenem datumu z dobro validacijo na koncu bolj ekonomičen.

Faza 4: Optimizacija, integriteta, zmogljivost, obratovalni procesi

Po preklopu se začne faza, v kateri naj MariaDB pokaže svoje prednosti: referenčna integriteta, performančni indeksi, urejene pravice, monitoring, testi backup/restore. Tu se pogosto pokažejo »resne« proizvodne obremenitve: dolga poročila, slabo indeksirana iskanja, paketna posodabljanja. Kontrolirana migracija to fazo izrecno načrtuje, namesto da bi bila le nenačrtovano popravilo.

Tipi podatkov in mapiranje: iz Paradox v MariaDB brez izgube informacij

Mapiranje polj je srce migracije. Tipične dodelitve (poenostavljeno) so:

• Alpha / Memo: VARCHAR/TEXT (z utf8mb4), preverjanje dolžin in pravila Trim
• Number: INT/BIGINT/DECIMAL glede na razpon vrednosti; previdnost pri implicitnih decimalkah
• Date/Time: DATE/DATETIME/TIMESTAMP; jasna pravila za »0-datum« oz. NULL
• Logical: BOOLEAN oziroma TINYINT(1) z enoznačno semantiko
• Currency: DECIMAL(…,2/4) namesto Float, da se izognemo napakam zaokroževanja

Pomembno ni le prevesti tipe, ampak tudi zabeležiti strokovna pravila: Ali je polje lahko NULL? Kateri privzeti podatki so strokovno pravilni? Katere kombinacije morajo biti enolične? Iz tega izhajajo omejitve in indeksi. Ta pravila so bila v Paradox/BDE-sistemu pogosto implicitno v UI ali kodi skrita – v MariaDB naj tam, kjer je smiselno, postanejo eksplicitna.

Integriteta: Primarni ključi, tuji ključi in enolični indeksi

Mnogo legacy-baz deluje leta brez referenčne integritete – dokler se ne pojavijo integracije, portali ali vzporedni procesi. Takrat kakovost podatkov postane omejujoči dejavnik. V MariaDB je mogoče uporabiti Foreign Keys, Unique Constraints in Checks (glede na različico/engine), da se napake podatkov preprečujejo zgodaj.

Praktična pot je postopno uvajanje integritete:

• Najprej primarni ključi in enolični indeksi na jedrnih objektih (stranke, artikli, dokumenti)
• Nato tuji ključi v stabilnih območjih
• Za »zgodovinske« tabele z neurejenimi podatki: najprej čiščenje, potem omejitve

To zmanjša tveganje, da bi preklop spodletel zaradi arhivskih ostankov, hkrati pa znatno izboljša celotno stanje.

Zmogljivost v praksi: kaj se spremeni z MariaDB

Paradox/BDE-sistemi so pogosto optimizirani za »datotečno hitrost«: lokalni indeksi, hitri dostopi do tabel, veliko filtiranja na strani odjemalca. Pri MariaDB se delo premakne na strežnik. To je dobro, vendar zahteva čisto SQL- in indeksno strategijo.

Tipične zmogljivostne pasti

• SELECT * iz velikih tabel, ker je prej lokalno dovolj hitro
• Filtriranje na strani odjemalca namesto strežniških WHERE-pogojev
• Manjkajoči sestavljeni indeksi na poljih iskalnih mask (npr. mandant + status + datum)
• LIKE ‚%text%‘ brez ustrezne strategije polnega besedila

Merljivo izboljšanje namesto »po občutku«

Kontrolirana migracija vzpostavi zgodaj merilne točke: Slow Query Log, Explain-analize, reproducibilne obremenitvene teste. To je posebej pomembno, če po migraciji načrtujete dodatne komponente, npr. REST-Server ali Kundenportal, ki generira nova vzorce dostopa (veliko majhnih zahtevkov, paginacija, iskalni endpointi).

Delphi-specifično: BDE-odstranitev, FireDAC in čisti sloji dostopa

V Delphi-projektih je tehnična modernizacija tesno povezana z dostopom do podatkov. BDE ni le »gonilnik«, ampak kompleten način dostopa (TTable, zapisno osnovan, navigacija, lokalni filtri). Migracija na MariaDB je pravi trenutek, da se ta dostop konsolidira.

Od »DataSetov povsod« k kontroliranemu dostopu do podatkov

Veliko aplikacij ima v vsakem obrazcu svoje poizvedbe. To slabo skalira strokovno in z vidika varnosti. Preizkušen pristop je prehod v smer:

• Centralne repository-/service-klasse za jedrne objekte
• Enotna obravnava napak in transakcij
• Parametrizirane poizvedbe (izogibanje SQL Injection, izkoriščanje plan-cachinga)
• Konfigurabilni connection-pooli oziroma upravljanje povezav za storitve

Tako nastane osnova za Layer-3 arhitekturo, v kateri sta UI, strokovna logika in persistenca jasno ločeni. To pomaga ne le pri zamenjavi baze, ampak tudi pri poznejšem razvoju v smeri REST-Serverjev ali ozadinskih storitev.

Povezava MariaDB z FireDAC: kaj je treba običajno doreči

V projektih se vedno znova pojavljajo ista vprašanja: katera različica gonilnika (MySQL/MariaDB), katere SSL-opcije, katere nastavitve časovnega pasu in datuma, katere nastavitve Unicode? To niso podrobnosti, saj neposredno vplivajo na konsistentnost podatkov (datum/čas), razvrščanje in varnost obratovanja (TLS). Kontrolirana migracija te parametre določi, jih dokumentira in preizkusi z realističnimi podatki.

Načrt preklopa: ključni datum, zamrznitev podatkov, povrnitev – brez presenečenj

Preklop je projekt sam po sebi. Dober načrt preklopa ne opisuje le »kdaj preklopiti«, ampak tudi zaščitne ukrepe:

• Zamrznitev podatkov: Od kdaj v starem sistemu ne bo več vnosov? Ali obstajajo nujni postopki?
• Končni uvoz: Koliko časa realno traja? (Suhi teki dajo številke.)
• Validacija: Kateri checks morajo biti »zeleni« pred sprostitvijo (štetja, vsote, vzorčenje, strokovna poročila)?
• Povrnitev: Kdaj se prekine in kako se nadaljuje?
• Komunikacija: Kdo daje soglasje? Kdo je dosegljiv v War Roomu?

Prav v srednjih podjetjih je »rollback« pogosto ne toliko tehnična kot organizacijska izziv. Zato mora biti migracija pripravljena tako, da preklop ni eksperiment, temveč preverjen postopek.

Po migraciji: osnova za REST, storitve in večplatformnost

Ko MariaDB stabilno teče in je BDE-odstranitev izvedena čisto, se odprejo nove možnosti: REST-API-ji za zunanje sisteme, ozadinsko procesiranje kot Windows- ali Linux-storitev, razvezava UI in strokovne logike ter perspektivno večplatformni odjemalci. Zelo pogosto je naslednji korak izvleči strokovno logiko iz namizja, da se integracije (ERP/DMS/CRM) in portali lahko upravljajo kontrolirano.

Pomembno je: REST-Server ni »dodatna plast«, temveč arhitekturna odločitev. Kdor je že konsolidiral dostop do podatkov, validacije in pooblastila v storitvah/repozitorijih, lahko iz tega bistveno lažje razvije robustne API-je.

Praktični kontrolni seznam: Kaj razjasniti pred začetkom projekta

• Kateri moduli so poslovno kritični in morajo na dan preklopa nemoteno delovati?
• Kakšni so realni volumni podatkov (velikosti tabel, rast, koncepti arhiviranja)?
• Katera poročila morajo biti 1:1 enaka in katera lahko izboljšamo?
• Katera integracija so odvisna od sistema (izvozi datotek, ODBC, Office, tiskovne poti)?
• Ali obstaja večmandantnost in če da: kako je danes predstavljena?
• Kateri obratovalni zahtevki veljajo (okna za backup, čas obnove, pravice, revizija)?

Ta razjasnitev ni birokracija, ampak preprečuje, da bi bila migracija »tehnično končana«, a strokovno nepriznata.

Zaključek: Kontrolirana migracija pomeni obvladovanje tveganj

Kontrolirana migracija Paradox in BDE na MariaDB pomeni modernizacijo aplikacije kot celotnega sistema: podatkovni model, SQL, transakcije, nabor znakov, sloj dostopa in obratovalni procesi. Kdor menjavo obravnava kot čisti izvoz, bo pogosto dobil natanko tiste probleme, ki se jih je želel znebiti – le da zdaj tečejo na novem strežniku.

Fazen pristop z reproducibilnim uvozom, natančnim mapiranjem polj, zgodnjo validacijo in jasno BDE-odstranitvijo (npr. preko FireDAC) ustvari stabilno osnovo: za večuporabniško delovanje, integracije, storitve in naslednje korake Delphi Modernisierung.

Če želite svojo migracijo strokovno načrtovati in izvesti brez prekinitve obratovanja, z veseljem obravnavamo izhodišče, tveganja in realističen fazni načrt: https://net-base-software-gmbh.de/kontakt/