Paradox i BDE kontrolisano migrirati na MariaDB

Mnoge Delphi-stručne aplikacije nastale su s Paradox-tabelama i Borland Database Engine (BDE), jer je to tada bio pragmatičan standard: lokalno, brzo spremno za rad, malo infrastrukture. U praksi ti sustavi često rade i danas u produkciji — uključujući reporting, ispis etiketa, import/export, batch-zadatke, historijske tablice i specijalnu logiku koja se godinama „ubrizgala“ u pristup podacima. Upravo zbog toga migracija nije samo izvoz podataka, nego kontrolisana rekonstrukcija: model podataka, SQL-ponašanje, nuspojave u kodu i operativni procesi moraju se sagledati zajedno.

MariaDB je kao ciljna platforma često vrlo dobar izbor kada je potrebna robusna višekorisnička obrada, čiste transakcije, centralizovane sigurnosne kopije, replikacija, jasna uprava privilegijama i mogućnost priključenja web-portala, servisa ili REST-API‑ja. Izazov rijetko leži u instalaciji baze podataka — stvarni napor je u sigurnom migracijskom putu: kako tablice, indeksi, Primary Keys, skupovi znakova, datumska polja, „prazne“ vrijednosti i referencijalne veze pravilno prenijeti, bez da se poslovna logika u radu pokida?

Ovaj tekst opisuje provjerenu proceduru za kontrolisanu migraciju iz Paradox i BDE u MariaDB: tehnički utemeljeno, etapno i sa fokusom na stabilnost. Cilj je održiva osnova za daljnje korake modernizacije — primjerice BDE-odluku, prelazak na BDE-Ablösung mit nativer Anbindung, jasna Layer-3 Architektur, REST-Server i multiplatformski klijenti.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

Paradox kao format datoteke i BDE kao sloj pristupa čine cjelovit sustav s osobitostima koje se u MariaDB ne bi trebale 1:1 „rekreirati“. Tipični simptomi u svakodnevnom radu su:

• Net transparente zavisnosti: SQL‑izjave su raspršene (forme, DataModules, reports, dinamički string‑SQL), često bez centralne governance.
• Ponašanje „po osjećaju“: Određeni filteri, sortiranja ili join‑ovi funkcioniraju slučajno, jer je Paradox/BDE tolerantan ili implicitno radi konverzije tipova.
• Ograničenja višekorisničkog rada: Zaključavanja na datotekama, padovi performansi na mreži, locking problemi pri rastu volumena podataka.
• Rizici održavanja: BDE-zavisnosti, stari drajveri, složeno deployment na modernim Windows-verzijama, 64‑Bit/ARM64 teme.

Kontrolisana migracija ove stavke ne tretira kao nuspojavu, nego kao kriterije uspjeha. MariaDB tada nije samo „nova baza“, nego prilika za dekompoziciju sloja pristupa podacima, povećanje poslovne integriteta i stvaranje interfejsne kompatibilnosti.

Zielbild: MariaDB als stabile Datenbasis für Desktop, Services und Portale

Smislen cilj za B2B poslovne aplikacije obično se sastoji od tri razine:

• Datenbank (MariaDB): konzistentno čuvanje podataka, indeksi, constraints, transakcije, korisnici/role, backupi.
• Fachlogik (Server/Services): validacije, workflowi, importeri, scheduleri, integracioni endpointe. Opcionalno kao REST-Server, Windows- ili Linux-Services.
• Clients (VCL/FMX/Web): korisnički interfejsi, izveštaji, offline dijelovi, integracije. Idealno uz jasne ugovore o poslovnoj logici.

Ovisno o početnoj situaciji, nije sve mora odmah biti implementirano. Ali migracija treba biti planirana tako da ne onemogući put ka čistoj arhitekturi. Ko danas samo kopira tablice i sutra ponovo „direktno“ iz svake forme piše u bazu, uveo je MariaDB, ali su stvarni rizici ostali.

Bestandsaufnahme: Was wirklich migriert werden muss

Na početku stoji inventura koja ide dalje od „koliko tablica“. U Paradox/BDE projektima tipično je baza samo dio istine. Važne tačke:

1) Tabellen, Indizes, „Pseudo‑Schlüssel“

Često nedostaju pravi primarni ključevi. Umjesto toga postoje kombinacije polja, tekući brojevi bez jedinstvenog constrainta ili „key“ polja koja se održavaju u aplikaciji. Za MariaDB od ovih mora nastati jedinstveni, robustni ključ — inače su transakcije i referencijalna integritet ograničeni u djelovanju.

2) Queries, dynamische SQL‑Bausteine, Reports

BDE koristi, ovisno o komponenti, različite SQL dijalekte i tolerira „kreativne“ izjave. Reporting‑komponente (uključujući starije) često sadrže vlastite SQL‑definicije. Migracija mora pronaći i kategorizirati te izvore: kritične kern‑queries, rijetko korištene analize, specijalni importi.

3) Zeichensatz und Sonderzeichen (Umlaute, ISO/ANSI, Unicode)

Mnoge Paradox‑aplikacije su historijski ANSI‑bazirane. Ako je Delphi‑aplikacija sama ikada prešla na Unicode, nastaju mješovite situacije: podaci su u starom encodingu, UI je Unicode, exporti očekuju Windows‑1252. MariaDB treba jasan koncept (tipično utf8mb4), uključujući čistu konverziju i testove na „nevidljive“ greške (usporedbe, sortiranje, Trim/Pad, specijalni znakovi).

4) „Leere“ Werte, Null‑Logik und Datumsfelder

Paradox/BDE poznaje razne posebne slučajeve: prazni stringovi umjesto NULL, 0‑datumi, „prazni“ timestamps, default vrijednosti koje nastaju u UI. MariaDB strogo razlikuje NULL i prazno. To utječe na WHERE‑klauzule, agregacije i izračune. Te razlike moraju se procijeniti za svaku tablicu/polje.

5) Nebenartefakte: Session‑Tabellen, lokale Konfiguration, Cache

Često se u Paradox‑strukturi nalaze lokalne tablice za međurezultate, export pufere, korisničke rasporede ili parametre. Dio toga i dalje treba ostati lokalno (npr. UI‑rasporedi), a dio treba centralno (npr. radni procesi, statusi, logovi). Migracija je prilika da se ove kategorije jasno odvoje.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

Da bi migracija bila planabilna, isplati se eksplicitno adresirati ponavljajuće razlike.

SQL‑Dialekt und Operatoren

BDE/Paradox‑SQL nije identičan MySQL/MariaDB‑SQL. Razlike se pojavljuju npr. kod datumski funkcija, string funkcija, outer joinova (historijski), Like/mask logike i implicitnih konverzija tipova. Kontrolirani pristup zamjenjuje „radi“ jasnim pravilima: Koje izjave se portiraju, koje se svjesno prepisuju, koje se enkapsuliraju u views/stored procedures (ako ima smisla)?

Sortierung und Collation

U Paradoxu su redosledi sortiranja i osjetljivost na velika/mala slova često drugačiji nego u MariaDB, posebno kod umlauta. U MariaDB collation (npr. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) određuje usporedbe i sortiranje. To nije akademsko pitanje: utječe na deduplikaciju, funkcije pretrage i ponašanje unique‑constrainta.

Autoincrement und Nummernkreise

Paradox ima autoincrement polja, ali aplikacije često koriste vlastite brojčanike (brojevi dokumenata, brojevi narudžbi) sa specijalnom logikom. U MariaDB treba jasno razdvojiti:

• Technischer Primärschlüssel: AUTO_INCREMENT (oder UUID, je nach Architektur) für Beziehungen.
• Fachliche Nummer: vlastiti brojčanik sa transakcijskom zaštitom, eventualno po mandantu/periodi.

Ko pokušava koristiti poslovni broj kao tehnički ključ, suočit će se kasnije s skupim preinakama.

Locking und Transaktionen

Prijelaz sa pristupa baziranog na datotekama na pravi server je dobitak, ali mijenja ponašanje. U MariaDB su transakcije (InnoDB) centralne. Treba odlučiti gdje su granice transakcija: po dijalogu, po spremanju, po batchu. Posebno važno: dugačke transakcije i „edit‑mode“ trajanja minuta su u Paradox‑svjetovima česti, ali na serverskoj strani rizični (lockovi, deadlockovi, replikacijski lag). Često je prilagodba radnih procesa ili UI‑a dio migracije.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

U B2B okruženjima operativna stabilnost često je važnija od naglog prekida. Etapni migracijski put smanjuje rizik jer poslovni odjel i IT mogu iterativno validirati.

Etappe 1: Datenmodell‑Transfer mit Mapping, ohne Code‑Umbau

U prvom koraku se gradi MariaDB‑schema koje preslikava Paradox‑strukturu — ali već s ciljanim principima: primarni ključevi, indeksi, odgovarajući tipovi, utf8mb4, InnoDB. Paralelno se razvija reproducibilan import proces (skripte/alati) koji se po potrebi može ponavljati. Bitna je ponovljivost, jer migracija rijetko bude „gotova“ nakon prvog pokretanja.

Deliverables ove etape su tipično:

• Schema‑definicija (DDL) verzionirana (npr. u Git)
• Lista mapiranja polja (Paradox → MariaDB) inkl. pravila konverzije
• Import‑procedura s logiranjem (broj zapisa, greške, outlajeri)
• Prvi validacijski izvještaji (counts, sume, checksums)

Etappe 2: BDE‑Ablösung im Datenzugriff (z. B. mit FireDAC)

Stvarni modernizacijski korak je deponovanje ovisnosti o BDE. U Delphi‑projektima BDE-Ablosung mit nativer Anbindung je provjeren put, jer nudi moderne drajvere, transakcije, bind parametara i jedinstvene komponente za različite SQL‑backende. Ključno nije samo „izbaciti BDE“, nego kako će nakon toga izgledati kod: centraliziran pristup podacima, jasna obrada grešaka, čisti parametri umjesto konkatenacije stringova.

Tipične zadaće u ovoj etapi:

• Ersetzen von TTable/TQuery durch FireDAC‑Queries und DataSets
• Einführen einer Data‑Access‑Schicht (DAL) kao osnova za kasniju Layer-3 arhitekturu
• Standardisierung von Transaktions‑Scopes (Commit/Rollback)
• SQL‑Review: Dialektanpassung, Parameter, Paging, Joins

Ako vaša aplikacija treba dugoročnu modernizaciju, ovaj korak je često važniji od same migracije podataka. On stvara tehničku slobodu za 64‑Bit, moderne Windows‑verzije i čiste deployment‑pipelina.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

Za kritične sustave smislen je paralelni rad: MariaDB se podiže i ciklički (ili inkrementalno) puni, dok legacy sustav i dalje radi. Time poslovni odjel može uspoređivati analize, identificirati rubne slučajeve i testirati novu platformu pod opterećenjem. Paralelni rad može se realizirati različito:

• Read‑only replika za pripremu reporting/BI
• „Dual Write“ u definisanim dijelovima (samo ako se kontrolira)
• Stichtagsmigration sa više dry‑runova i jasnom cutover‑checklistom

Važno je ne pretjerati s kompleksnošću: Dual‑Write zvuči privlačno, ali je rizično ako poslovna logika nije centralizirana. Često je ponovljiv stichtag‑run s dobrim validacijama na kraju isplativiji.

Etappe 4: Optimierung, Integrität, Performance, Betriebsprozesse

Nakon cutover‑a počinje faza u kojoj MariaDB treba pokazati svoje prednosti: referencijalna integritet, perfomantni indeksi, čiste privilegije, monitoring, backup/restore testovi. Tek tada se često pojave „prave“ produkcijske opterećenja: dugi reports, loše indek­sirane maske za pretragu, batch‑updatei. Kontrolisana migracija eksplicitno planira ovu etapu, umjesto da se ostavi kao nenačinjeni posao.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

Mapiranje polja je srce migracije. Tipične dodjele (pojednostavljeno) su:

• Alpha / Memo: VARCHAR/TEXT (mit utf8mb4), provjere dužine i Trim‑pravila
• Number: INT/BIGINT/DECIMAL ovisno o opsegu vrijednosti; oprez kod implicitnih decimala
• Date/Time: DATE/DATETIME/TIMESTAMP; jasna pravila za „0‑datum“ odnosno NULL
• Logical: BOOLEAN bzw. TINYINT(1) s jasnom semantikom
• Currency: DECIMAL(… ,2/4) umjesto float, da se izbjegnu greške zaokruživanja

Važno je ne samo prevesti tipove već i dokumentirati poslovna pravila: Smije li polje biti NULL? Koje su ispravne default vrijednosti? Koje kombinacije moraju biti jedinstvene? Iz toga nastaju constraints i indeksi. Ta su pravila u Paradox/BDE sustavu često bila implicitna u UI‑u ili kodu — u MariaDB‑u bi, gdje ima smisla, trebala postati eksplicitna.

Integrität: Primary Keys, Foreign Keys und eindeutige Indizes nachziehen

Mnoge legacy baze godinama rade bez referencijalne integriteta — dok se ne pojave integracije, portali ili paralelni procesi. Tada kvaliteta podataka postaje ograničavajući faktor. U MariaDB se mogu koristiti Foreign Keys, Unique Constraints i CHECK (ovisno o verziji/engineu) za rano sprječavanje grešaka u podacima.

Praktičan put je uvođenje integriteta stupnjevito:

• Najprije Primary Keys i jedinstveni indeksi na ključnim objektima (kupci, artikli, dokumenti)
• Zatim Foreign Keys u stabilnim područjima
• Za „historijske“ tablice s prljavim podacima: prvo čišćenje, potom constraints

To smanjuje rizik da cutover zakaže zbog starih tereta, a istovremeno znatno poboljšava opće stanje.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE sustavi su često optimizirani za „brzinu datoteke“: lokalni indeksi, brzi pristupi tabelama, puno klijentske filtracije. U MariaDB se rad prebacuje na server. To je dobro, ali zahtijeva čistu SQL‑ i indeksnu strategiju.

Typische Performance‑Fallen

• SELECT * iz velikih tablica, jer je ranije „lokalno“ bilo dovoljno brzo
• Klijentsko filtriranje umjesto server‑side WHERE‑klauzula
• Manjak složenih indeksnih kombinacija za pretrage (npr. Mandant + Status + Datum)
• LIKE ‚%text%‘ bez odgovarajuće fulltext strategije

Messbar verbessern statt „nach Gefühl“

Kontrolisana migracija rano uspostavlja mjerne točke: Slow Query Log, Explain‑analize, reproducibilni load‑testovi. To je posebno važno ako nakon migracije planirate dodatne komponente, npr. REST‑Server ili Kundenportal, koje mijenjaju obrasce pristupa (mnoštvo malih zahtjeva, paging, endpoints za pretrage).

Delphi‑spezifisch: BDE‑Ablösung, FireDAC und saubere Zugriffsschichten

U Delphi‑projektima tehnička modernizacija je tijesno povezana s pristupom podacima. BDE nije samo „drajver“, nego kompletan stil pristupa (TTable, record‑oriented, navigacija, lokalni filteri). Migracija u MariaDB je pravi trenutak za konsolidaciju pristupa.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Mnoge aplikacije imaju u svakoj formi vlastite queries. To slabo skaluje i sa stajališta sigurnosti i funkcionalnosti. Provjeren je pomak prema:

• Centralne repository/service klase za ključne objekte
• Jedinstvena obrada grešaka i transakcija
• Parametrizirane upite (sprječavanje SQL injectiona, iskoristiti plan caching)
• Konfigurabilni connection‑poolovi odnosno upravljanje konekcijama za servise

Time se stvara osnova za Layer-3 arhitekturu u kojoj UI, poslovna logika i persistencija budu jasno odvojeni. To pomaže ne samo pri promjeni baze, nego i pri kasnijem širenju prema REST‑serverima ili background servisima.

MariaDB‑Anbindung mit FireDAC: was typischerweise zu klären ist

U projektima se često pojavljuju ista pitanja: koja drajver varijanta (MySQL/MariaDB), koje SSL opcije, timezone i date opcije, koji Unicode‑sve‑setinzi? To nisu sitnice, jer direktno utječu na konzistenciju podataka (datum/vrijeme), sortiranje i sigurnost poslovanja (TLS). Kontrolisana migracija definira te parametre, dokumentira ih i testira s realističnim podacima.

Cutover‑Plan: Stichtag, Datenfreeze, Rollback – ohne Überraschungen

Cutover je projekt sam za sebe. Dobar cutover‑plan ne opisuje samo „kada se prebaciti“, već i zaštitne mjere:

• Datenfreeze: Od kada se u starom sustavu više ništa ne unosi? Postoje li izvanredni procesi?
• Finaler Import: Koliko realno traje? (Dry‑runovi daju brojke.)
• Validierung: Koje provjere moraju biti „zeleno“ prije puštanja (counts, sume, uzorci, poslovni izvještaji)?
• Rollback: Kada se prekida i kako se nakon toga postupa?
• Kommunikation: Tko daje odobrenje? Tko je dostupan u war room‑u?

U srednjim poduzećima rollback često nije tehničko pitanje, nego organizacijsko. Zato migracija mora biti toliko pripremljena da cutover nije eksperiment, nego probani postupak.

Nach der Migration: Basis für REST, Services und Multiplattform

Kad MariaDB stabilno radi i BDE‑odluka je izvršena, otvaraju se nove mogućnosti: REST‑API‑ji za vanjske sustave, background obrada kao Windows‑ ili Linux‑servisi, razdvajanje UI‑a i poslovne logike te perspektivno multiplatformski klijenti. Čest sljedeći korak je izvlačenje poslovne logike iz desktopa kako bi se integracije (ERP/DMS/CRM) i portali kontrolisano opsluživali.

Važno: REST‑Server nije „dodatni sloj“, nego arhitektonska odluka. Tko je već konsolidirao pristup podacima, validacije i autorizaciju u servisima/repositoryjima, puno lakše razvija robusne API‑je.

Praxis‑Checkliste: Was Sie vor Projektstart klären sollten

• Koji moduli su poslovno kritični i moraju na dan cutover‑a sigurno raditi?
• Kako izgledaju realni volumeni podataka (veličine tablica, rast, arhivski koncepti)?
• Koji izvještaji moraju biti 1:1 identični, koji se smiju poboljšati?
• Koje integracije ovise o sustavu (file‑exporti, ODBC, Office, print‑linije)?
• Postoji li multi‑tenant podrška i ako da: kako je danas realizirana?
• Koji su operativni zahtjevi (window za backup, vrijeme restorea, prava, audit)?

Ta pojašnjenja nisu birokracija, nego sprječavaju da migracija bude „tehnički završena“, ali poslovno neprihvatljiva.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

Kontrolisana migracija iz Paradox i BDE u MariaDB znači modernizirati aplikaciju kao cjelinu: model podataka, SQL, transakcije, skupove znakova, sloj pristupa podacima i operativne procese. Tko promjenu promatra samo kao čist izvoz, često dobije iste probleme koje je želio riješiti — samo na novom serveru.

Etapni pristup s reproducibilnim importom, jasnim mapiranjem polja, ranom validacijom i jasnom BDE‑odlukom (npr. preko FireDAC) gradi stabilnu osnovu: za višekorisnički rad, za integracije, za servise i za naredne korake Delphi Modernisierung.

Ako želite svoju migraciju stručno planirati i izvesti bez prekida u radu, rado ćemo razmotriti početnu situaciju, rizike i realističan etapni plan: https://net-base-software-gmbh.de/kontakt/