Paradox i BDE kontrolirano migrirati na MariaDB

Mnoge Delphi-stručne aplikacije nastale su s Paradox-tablicama i Borland Database Engine ( BDE ), jer je to tada bio pragmatičan standard: lokalno, brzo za pokretanje, malo infrastrukture. U praksi ti sustavi često i danas rade produktivno — uključujući reporting, ispis etiketa, import/export, batch-poslove, tablice povijesti i posebnu logiku koja se tijekom godina „umela“ u pristup podacima. Upravo zato migracija nije samo izvoz podataka, već kontrolirana preinaka: model podataka, SQL-ponašanje, nuspojave u kodu i operativni procesi moraju se sagledati zajedno.

MariaDB je često vrlo dobar cilj ako se traži robusno višekorisničko okruženje, čiste transakcije, centralizirane backup-e, replikacija, jasna uprava pravima i mogućnost povezivanja s web-portalom, servisima ili REST-API-jima. Izazov rijetko leži u instalaciji baze podataka — stvarni napor je u sigurnom migracijskom putu: kako će se tablice, indeksi, primarni ključevi, skupovi znakova, polja datuma, „prazne“ vrijednosti i referencijalne veze ispravno prenijeti, bez da poslovna logika u radu zakaže?

Ovaj članak opisuje provjerenu proceduru za kontroliranu migraciju iz Paradox-a i BDE u MariaDB: tehnički utemeljeno, etapno i s fokusom na stabilnost. Cilj je održiva osnova za daljnje korake modernizacije — primjerice BDE-zamjenu, prijelaz na BDE-Ablösung mit nativer Anbindung, jasnu Layer-3 arhitekturu, REST-server i klijente koji rade na više platformi.

Zašto je migracija Paradox/BDE više od promjene baze podataka

Paradox kao format datoteke i BDE kao pristupni sloj čine cjelovit sustav s osobitostima koje u MariaDB nije poželjno reproducirati 1:1. Tipični simptomi u svakodnevnom radu su:

• Nepregledne ovisnosti: SQL-izrazi su raštrkani (forme, DataModules, izvještaji, dinamički string-SQL), često bez centralne uprave.
• Ponašanje „po osjećaju“: Određeni filteri, sortiranja ili join-ovi rade slučajno jer je Paradox/BDE tolerantna ili implicitno konvertira tipove.
• Granice višekorisničkog rada: zaključavanje datoteka, padovi performansi u mreži, problemi s locking-om kako raste volumen podataka.
• Rizici održavanja: BDE-ovisnosti, stari drajveri, zahtjevno deployment na modernim Windows verzijama, 64‑Bit/ARM64 pitanja.

Kontrolirana migracija ne smatra ove točke sporednim efektom, već ih postavlja kao kriterije uspjeha. MariaDB tada nije samo „nova baza“, već prilika za razdvajanje sloja pristupa podacima, povećanje poslovne integriteta i uspostavu sučelja.

Ciljni model: MariaDB kao stabilna baza za desktop, servise i portale

Razumno ciljno stanje za B2B-aplikacije obično se sastoji od tri sloja:

• Baza podataka (MariaDB): konzistentno pohranjivanje podataka, indeksi, ograničenja, transakcije, korisnici/role, backup-i.
• Poslovna logika (Server/Services): validacije, workflow-i, importeri, scheduleri, sučelja. Opcionalno kao REST-server, Windows- ili Linux-servisi.
• Klijenti (VCL/FMX/Web): korisnička sučelja, izvještaji, offline-dijelovi, integracije. Idealno s jasnim ugovorima prema poslovnoj logici.

Ovisno o početnom stanju, nije nužno odmah realizirati sve. No migracija bi trebala biti planirana tako da ne zatvori put ka čistoj arhitekturi. Tko danas samo kopira tablice i sutra opet „direktno“ iz svakog obrasca čita i piše u bazu, uveo je MariaDB, ali stvarni rizici ostaju.

Inventura: što se zapravo mora migrirati

Na početku je inventura koja nadilazi pitanje „koliko tablica“. U Paradox/BDE projektima tipično je da je baza samo dio istine. Ključne točke:

1) Tablice, indeksi, „pseudo-ključevi“

Često nedostaju pravi primarni ključevi. Umjesto toga postoje kombinacije polja, tekući brojevi bez jedinstvenog ograničenja ili „ključna“ polja koja se održavaju u aplikaciji. Za MariaDB iz toga moraju nastati jedinstveni, pouzdani ključevi — inače su transakcije i referencijalna integriteta samo djelomično učinkoviti.

2) Upiti, dinamičke SQL-komponente, izvještaji

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

3) Skup znakova i posebni znakovi (umlauti, ISO/ANSI, Unicode)

Mnogo Paradox-aplikacija je povijesno bilo bazirano na ANSI kodnim stranicama. Ako je Delphi aplikacija sama po sebi u nekom trenutku prešla na Unicode, nastaju miješane situacije: podaci su u starom enkodingu, UI je Unicode, exporti očekuju Windows-1252. MariaDB bi trebala dobiti jasan koncept (obično utf8mb4), uključujući čistu konverziju i testove na „nevidljive“ greške (usporedbe, sortiranje, Trim/Pad, posebni znakovi).

4) „Prazne“ vrijednosti, logika NULL i polja datuma

Paradox/BDE poznaje razne posebne slučajeve: prazni stringovi umjesto NULL, 0-podaci, „prazni“ timestampi, zadane vrijednosti koje nastaju u UI-u. MariaDB strogo razlikuje između NULL i praznog stringa. To utječe na WHERE-klauzule, agregacije i izračune. Ove razlike moraju se po tabeli/polju procijeniti.

5) Sporedni artefakti: session-tablice, lokalna konfiguracija, cache

Često u Paradox-strukturi postoje lokalne tablice za međurezultate, export-pufere, korisničke layout-e ili parametre. Neke stvari trebaju ostati lokalne (npr. UI-layout-i), druge trebaju biti centralizirane (npr. radni procesi, statusi, logovi). Migracija je prilika da se te kategorije jasno odvoje.

Sablasti pri Paradox/BDE: tipične tehničke razlike

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

SQL-dijalekt i operatori

BDE/Paradox-SQL nije identičan MySQL/MariaDB-SQL. Razlike se pojavljuju npr. kod funkcija za datum, string-funkcija, outer join-ova (povijesno), Like/maske logike i kod implicitnih tip-konverzija. Kontrolirani pristup zamjenjuje „radi ionako“ jasnim pravilima: koji se izrazi portaju, koji se svjesno prepisuju, koji se enkapsuliraju u view-e/stored procedure (ako je smisleno)?

Sortiranje i collation

U Paradox-u su redoslijedi sortiranja i osjetljivost na velika/mala slova često drugačiji nego u MariaDB, posebice kod umlauta. U MariaDB collation (npr. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) odlučuje o usporedbama i sortiranju. To nije akademsko pitanje: utječe na deduplikaciju, funkcije pretraživanja i ponašanje unique-ograničenja.

Autoincrement i nizovi brojeva

Paradox ima polja s autoincrementom, ali aplikacije često koriste vlastite nizove brojeva (brojevi dokumenata, brojevi naloga) sa posebnom logikom. U MariaDB treba to jasno razdvojiti:

• Tehnički primarni ključ: AUTO_INCREMENT (ili UUID, ovisno o arhitekturi) za relacije.
• Poslovni broj: vlastiti brojčani niz s transakcijskim zaštitama, eventualno po mandantu/periodu.

Tko pokuša poslovni broj zloupotrijebiti kao tehnički ključ, suočit će se kasnije s skupim preinakama.

Zaključavanje i transakcije

Prijelaz s pristupa baziranog na datotekama na pravi serverski pristup je dobitak, ali mijenja ponašanje. U MariaDB su transakcije (InnoDB) centralne. Treba odlučiti gdje su transakcijske granice: po dijalogu, po operaciji spremanja, po batchu. Posebno važno: dugačke transakcije i „edit-mode“ u trajanju od minuta su u Paradox-svjetovima česte, ali na serverskoj strani problematične (lockovi, deadlock-ovi, replicacijsko kašnjenje). Prilagodba radnih navika ili UI-a često je dio migracije.

Model postupka: kontrolirana migracija u fazama umjesto Big Bang-a

U B2B okruženjima stabilnost operacija često je važnija od brzog rezanja. Postupno migracijsko rješenje smanjuje rizik jer poslovna jedinica i IT mogu iterativno validirati.

Faza 1: transfer modela podataka s mapiranjem, bez izmjene koda

U prvom koraku se gradi MariaDB-shemа koji preslikava Paradox-strukturu — ali već s ciljnim principima: primarni ključevi, indeksi, odgovarajući tipovi, utf8mb4, InnoDB. Paralelno se razvija reproducibilan import-proces (skripte/alatke) koji se po potrebi može ponoviti. Ključno je ponovljivost, jer migracija rijetko bude „gotova“ nakon prvog izvođenja.

Deliverable-i ove faze su tipično:

• Definicija sheme (DDL) verzionirana (npr. u Gitu)
• Lista mapiranja polja (Paradox → MariaDB) uključujući pravila konverzije
• Import-procedura s logiranjem (broj zapisa, greške, outlieri)
• Prvi validacijski izvještaji (brojanja, zbrojevi, checksumi)

Faza 2: BDE-zamjena u pristupu podacima (npr. s FireDAC)

Stvarni modernizacijski korak je odvajanje od BDE. U Delphi projektima BDE-Ablosung mit nativer Anbindung je provjeren put jer nudi moderne drajvere, transakcije, vezivanje parametara i jedinstvene komponente za različite SQL-backend-e. Ključno nije „BDE van“, već kako kod potom izgleda: centralizirani pristup podacima, jasna obrada grešaka, čisti parametri umjesto konkatenacije stringova.

Tipični zadaci u ovoj fazi:

• Zamjena TTable/TQuery s FireDAC-Query-ima i DataSet-ima
• Uvođenje Data-Access-sloja (DAL) kao osnove za kasniju Layer-3 arhitekturu
• Standardizacija transakcijskih opsega (Commit/Rollback)
• SQL-review: prilagodba dijalekta, parametri, paging, join-ovi

Ako vaša aplikacija treba dugoročno 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-pipeline-ove.

Faza 3: paralelni rad i poslovna primopredaja bez prekida rada

Za kritične sustave ima smisla paralelni rad: MariaDB se podiže i ciklički (ili inkrementalno) puni dok stari sustav dalje radi. Time poslovna jedinica može uspoređivati izvještaje, identificirati rubne slučajeve i testirati novu platformu pod opterećenjem. Paralelni rad može se ostvariti na različite načine:

• Read-only-replica za pripremu reporting/BI-a
• „Dual Write“ u definiranim područjima (samo ako je dobro kontrolirano)
• Stichtagsmigration s više probnih pokusa i jasnom cutover-checklistom

Važno je ne pretjerivati u kompleksnosti: Dual-Write zvuči privlačno, ali je sklono pogreškama ako poslovna logika nije centralizirana. Često je reproducibilni Stichtag-run s dobrim validacijama na kraju ekonomičniji.

Faza 4: optimizacija, integritet, performanse, operativni procesi

Nakon Cutover-a započinje faza u kojoj MariaDB treba pokazati svoje prednosti: referencijalna integriteta, performansni indeksi, čista prava, monitoring, backup/restore testovi. Tek tada često postanu vidljivi „stvarni“ produkcijski load-ovi: dugi izvještaji, loše indeksirana polja pretraživanja, batch-azuriranja. Kontrolirana migracija eksplicitno planira ovu fazu, umjesto da nastane kao nenačrtovani naknadni rad.

Tipovi podataka i mapiranje: iz Paradox-a u MariaDB bez gubitka informacija

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

• Alpha / Memo: VARCHAR/TEXT (s utf8mb4), provjera duljina i pravila Trim
• Number: INT/BIGINT/DECIMAL ovisno o rasponu vrijednosti; oprez kod implicitnih decimala
• Date/Time: DATE/DATETIME/TIMESTAMP; jasna pravila za „0-datum“ odnosno NULL
• Logical: BOOLEAN odnosno TINYINT(1) s nedvosmislenom sematikom
• Currency: DECIMAL(…,2/4) umjesto float-a kako bi se izbjegle pogreške zaokruživanja

Važno je ne samo prevesti tipove podataka, već i zabilježiti poslovna pravila: smije li polje biti NULL? Koje su ispravne default-vrijednosti iz poslovne perspektive? Koje kombinacije moraju biti jedinstvene? Iz toga proizlaze ograničenja i indeksi. Ta su pravila u Paradox/BDE sustavima često implicitna u UI-u ili kodu — u MariaDB bi, gdje je smisleno, trebala postati eksplicitna.

Integritet: primarni ključevi, strani ključevi i jedinstveni indeksi

Mnoge legacy-baze rade godinama bez referencijalne integritete — dok integracije, portali ili paralelni procesi ne dođu. Tada kvaliteta podataka postaje ograničavajući faktor. U MariaDB se mogu upotrijebiti Foreign Keys, Unique Constraints i Checks (ovisno o verziji/engi­ne) kako bi se greške u podacima ranije spriječile.

Praktičan pristup je uvoditi integritet fazno:

• Prvo primarni ključevi i jedinstveni indeksi na ključnim objektima (kupci, artikli, dokumenti)
• Zatim strani ključevi u stabilnim područjima
• Za „povijesne“ tablice pune otpada: prvo čišćenje, pa ograničenja

To smanjuje rizik da Cutover ne uspije zbog naslijeđa i istovremeno značajno poboljšava ukupno stanje.

Performanse u praksi: što se mijenja s MariaDB

Paradox/BDE sustavi su često optimizirani za „brzinu datoteke“: lokalni indeksi, brzi pristupi tablicama, puno filtriranja na klijentu. S MariaDB rad se premješta na server. To je dobro, ali zahtijeva čiste SQL- i indeksne strategije.

Tipične performansne zamke

• SELECT * iz velikih tablica, jer je ranije „lokalno“ bilo dovoljno brzo
• Filtriranje na klijentu umjesto WHERE-klauzula na serveru
• Nedostatak složenih indeksa za polja pretraživanja (npr. mandant + status + datum)
• LIKE ‚%text%‘ bez odgovarajuće strategije za fulltext

Mjerljivo poboljšanje umjesto „po osjećaju“

Kontrolirana migracija rano uspostavlja mjerne točke: Slow Query Log, Explain-analize, reproducibilni load-testovi. To je posebno važno ako se nakon migracije planiraju dodatne komponente, npr. REST-server ili Kundenportal, koji stvaraju nova obrasca pristupa (mnoštvo malih zahtjeva, paging, endpoint-i za pretrage).

Delphi-specifično: BDE-zamjena, FireDAC i čisti pristupni slojevi

U Delphi projektima je tehnička modernizacija usko povezana s pristupom podacima. BDE nije samo „drajer“, već kompletan stil pristupa (TTable, rad po zapisima, navigacija, lokalni filteri). Migracija na MariaDB je pravi trenutak za konsolidaciju pristupa.

Od „DataSet-a svugdje“ do kontroliranog pristupa podacima

Mnoge aplikacije imaju u svakom formu svoje upite. To loše skalira s poslovnog i sigurnosnog aspekta. Provjeren je preokret prema:

• Središnjim repository-/service-klasama za ključne objekte
• Jedinstvenom obradi grešaka i transakcija
• Parametriziranim upitima (sprječavanje SQL Injection-a, korištenje plan-cache-a)
• Konfigurabilnim connection-pool-ovima odnosno upravljanjem konekcijama za servise

Tako nastaje osnova za Layer-3 arhitekturu u kojoj su UI, poslovna logika i perzistencija jasno odvojeni. To pomaže ne samo pri zamjeni baze, već i pri kasnijem proširenju prema REST-serverima ili background-servisima.

Povezivanje s MariaDB preko FireDAC: tipična pitanja

U projektima se stalno pojavljuju ista pitanja: koja varijanta drajvera (MySQL/MariaDB), koje SSL-opcije, koje timezone i datum-opsije, koje Unicode-postavke? To nisu sitnice, jer utječu izravno na konzistentnost podataka (datum/vrijeme), sortiranje i operativnu sigurnost (TLS). Kontrolirana migracija definira te parametre, dokumentira ih i testira s realističnim podacima.

Cutover-plan: datum, zamrzavanje podataka, rollback — bez iznenađenja

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

• Datafreeze: Od kada se u starom sustavu više ne unose podaci? Postoje li postupci za hitne slučajeve?
• Finalni import: Koliko realno traje? (probe daju brojke.)
• Validacija: Koje provjere moraju biti zelene prije odobrenja (brojanja, zbrojevi, uzorci, poslovni izvještaji)?
• Rollback: Kada se prekida i kako se tada nastavlja?
• Komunikacija: Tko daje odobrenje? Tko je dostupan u War Room-u?

U srednjim poduzećima „rollback“ često nije tehnički, već organizacijski izazov. Zato migracija mora biti pripremljena tako da cutover nije eksperiment, već isprobani proces.

Nakon migracije: osnova za REST, servise i multiplatformu

Kada MariaDB radi stabilno i BDE-zamjena je ispravno izvedena, otvaraju se nove opcije: REST-API-ji za vanjske sustave, pozadinska obrada kao Windows- ili Linux-servisi, razdvajanje UI-a od poslovne logike i perspektivno multiplatform klijenti. Čest sljedeći korak je izvući poslovnu logiku iz desktopa kako bi se integracije (ERP/DMS/CRM) i portali mogli kontrolirano opsluživati.

Važno je: REST-server nije „dodatni sloj“, već arhitektonska odluka. Tko je već konsolidirao pristup podacima, validacije i autorizacije u servise/repository-e, lakše će razviti robusne API-je.

Praktična kontrolna lista: što razjasniti prije početka projekta

• Koji moduli su poslovno kritični i moraju na dan Cutover-a sigurno raditi?
• Kako izgledaju realni volumeni podataka (veličine tablica, rast, arhivske strategije)?
• Koji izvještaji moraju biti 1:1 identični, a koji smiju biti poboljšani?
• Koje integracije ovise o sustavu (exporti datoteka, ODBC, Office, print-linije)?
• Postoji li podrška za više mandanata i ako da: kako je danas modelirana?
• Koji operativni zahtjevi vrijede (backup prozori, vrijeme restore-a, prava, audit)?

Ta razjašnjenja nisu birokracija, već sprječavaju da migracija bude „tehnički završena“, ali poslovno neprihvaćena.

Zaključak: kontrolirana migracija znači upravljati rizicima

Kontrolirana migracija iz Paradox-a i BDE u MariaDB znači modernizirati aplikaciju kao cjeloviti sustav: model podataka, SQL, transakcije, skupovi znakova, pristupni sloj i operativni procesi. Tko promjenu promatra kao puki izvoz, često će dobiti upravo probleme koje je želio ukloniti — samo na novom serveru.

Etapni pristup s reproducibilnim importom, čistim mapiranjem polja, ranim validacijama i jasnom BDE-zamjenom (npr. preko FireDAC) stvara stabilnu osnovu: za višekorisnički rad, za integracije, za servise i za naredne korake Delphi Modernisierung.

Ako želite svoju migraciju stručno isplanirati i provesti bez prekida u radu, rado ćemo razgovarati o početnoj situaciji, rizicima i realističnom planu faza: https://net-base-software-gmbh.de/kontakt/