Paradox и BDE — контролисана миграција на MariaDB

Mnoge Delphi-stručne aplikacije nastale su sa 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 sistemi često rade u produkciji i danas – uključujući izveštavanje, štampu etiketa, Import/Export, batch-poslove, tabele istorije i posebnu logiku koja se godinama „utkala“ u pristup podacima. Upravo zato migracija nije samo izvoz podataka, već kontrolisana rekonstrukcija: model podataka, SQL-ponašanje, neželjeni efekti u kodu i operativni procesi moraju se sagledati zajedno.

MariaDB je kao ciljna platforma često vrlo dobar izbor kada je u pitanju robustan višekorisnički rad, konzistentne transakcije, centralne bekapove, replikacija, jasna uprava pravima i mogućnost povezivanja sa web-portalima, servisima ili REST-API-jima. Izazov retko leži u instalaciji baze podataka – pravi napor je u sigurnom putu migracije: kako tabele, indeksi, primarni ključevi, skupovi karaktera, polja datuma, „prazne“ vrednosti i referencijalne veze biti ispravno preneti, bez da poslovna logika u radu pukne?

Ovaj tekst opisuje proveren pristup za kontrolisanu migraciju iz Paradox-a i BDE u MariaDB: tehnički utemeljen, fazno i sa fokusom na stabilnost. Cilj je održiva osnova za dalje korake modernizacije – na primer BDE-zamenу, prelazak na BDE-Ablösung mit nativer Anbindung, jasnu Layer-3 Architektur, REST-Server i platformno-prilagodljive klijente.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

Paradox kao format fajla i BDE kao sloj pristupa čine jedinstven sistem sa specifičnostima koje se u MariaDB ne bi trebalo 1:1 „rekonstruisati“. Tipični simptomi u svakodnevnom radu su:

• Intransparente Abhängigkeiten: SQL-naredbe su razbacane (forme, DataModules, izveštaji, dinamički string-SQL), često bez centralne uprave.
• Verhalten „nach Gefühl“: Određeni filteri, sortiranja ili join-ovi rade slučajno, zato što je Paradox/BDE tolerantno ili implicitno konvertuje tipove.
• Mehrbenutzer-Grenzen: Zaključavanja na nivou fajla, padovi performansi preko mreže, problemi sa locking-om kako raste obim podataka.
• Wartungsrisiken: BDE-zavisnosti, stari drajveri, komplikovano deployment na modernim Windows-verzijama, 64‑Bit/ARM64-teme.

Kontrolisana migracija ne tretira ove tačke kao neplanirane nuspojave, već ih postavlja kao kriterijume cilja. MariaDB tada nije samo „nova baza“, već prilika da se sloj pristupa podacima razdvoji, poveća poslovna integritet i uspostave interfejsi.

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

Razumno ciljano stanje za B2B-aplikacije obično se sastoji iz tri nivoa:

• Datenbank (MariaDB): konzistentno čuvanje podataka, indeksi, ograničenja, transakcije, korisnici/role, backupi.
• Fachlogik (Server/Services): validacije, workflow-i, importeri, scheduler, interfejsi. Opcionalno kao REST-Server, Windows- ili Linux-Services.
• Clients (VCL/FMX/Web): korisnička sučelja, izveštaji, offline-komponente, integracije. Idealno sa jasnim ugovorima o poslovnoj logici.

U zavisnosti od polazne tačke ne mora sve odmah biti realizovano. Ali migracija treba biti planirana tako da ne zatvori put ka čistoj arhitekturi. Ko danas samo kopira tabele a sutra ponovo „direktno“ iz svakog formulara piše u bazu, uveo je MariaDB, ali osnovni rizici ostaju.

Bestandsaufnahme: Was wirklich migriert werden muss

Na početku je inventar koji ide dalje od „koliko tabela“. U Paradox/BDE projektima tipično je da je baza samo deo istine. Važne tačke:

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

Često fale pravi primarni ključevi. Umesto toga postoje kombinacije polja, tekući brojevi bez jedinstvenog ograničenja ili „key“ polja koja se održavaju unutar aplikacije. Za MariaDB od toga moraju postati jedinstveni, pouzdani ključevi – inače su transakcije i referencijalni integritet ograničeno efikasni.

2) Queries, dynamische SQL-Bausteine, Reports

BDE koristi, zavisno od komponente, različite SQL-dijalekte i toleriše „kreativne“ naredbe. Reporting-komponente (uključujući starije) često sadrže sopstvene SQL-definicije. Migracija mora te izvore pronaći i kategorizovati: kritične osnovne upite, retko korišćene izveštaje, specijalne importe.

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

Mnoge Paradox-aplikacije su istorijski bazirane na ANSI. Ako je Delphi-aplikacija u međuvremenu prešla na Unicode, nastaju mešoviti slučajevi: podaci su u starom enkodingu, UI je Unicode, exporti očekuju Windows-1252. MariaDB treba jasan koncept (obično utf8mb4), uključujući pravilnu konverziju i testove na „nevidljive“ greške (poređenja, sortiranje, trim/pad, specijalni karakteri).

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

Paradox/BDE poznaje razne posebne slučajeve: prazni stringovi umesto NULL, 0-datumi, „prazni“ timestamp-i, default vrednosti koje nastaju u UI. MariaDB strogo razlikuje NULL i prazan string. To utiče na WHERE-klauzule, agregacije i izračune. Te razlike moraju se proceniti po tabeli/polju.

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

Često u Paradox-strukturi postoje lokalne tabele za međurezultate, export-bufere, korisničke layout-e ili parametre. Nešto treba ostati lokalno (npr. UI-layout-i), drugo treba centralizovati (npr. radne jedinice, statusi, logovi). Migracija je prilika da se te kategorije jasno razdvoje.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

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

SQL-Dialekt und Operatoren

BDE/Paradox-SQL nije identičan MySQL/MariaDB-SQL. Razlike se javljaju npr. kod funkcija za datum, funkcija za string, outer join-ova (istorijski), logike Like/maski i kod implicitnih konverzija tipova. Kontrolisani pristup zamenjuje „radi već“ jasnim pravilima: koje naredbe se portuju, koje se svesno prepisuju, a koje se enkapsuliraju u view-e/stored procedure (ako ima smisla)?

Sortierung und Collation

U Paradox-u su redosledi sortiranja i osetljivost na velika/mala slova često drugačiji nego u MariaDB, naročito kod Umlauta. U MariaDB collation (npr. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) odlučuje o poređenju i sortiranju. To nije akademsko pitanje: utiče na deduplikaciju, funkcije pretrage i ponašanje unique-ograničenja.

Autoincrement und Nummernkreise

Paradox ima polja sa automatskim inkrementom, ali aplikacije često koriste sopstvene brojačke serije (brojevi dokumenata, brojevi naloga) sa posebnom logikom. U MariaDB treba jasno razdvojiti:

• Technischer Primärschlüssel: AUTO_INCREMENT (ili UUID, zavisno od arhitekture) za relacije.
• Fachliche Nummer: sopstvena brojačka serija sa tranzakcijskom zaštitom, eventualno po mandantu/periodu.

Ko pokušava da fachliche Nummer koristi kao tehnički ključ, suočiće se kasnije sa skupim preinakama.

Locking und Transaktionen

Prelazak sa pristupa na nivou fajla na pravi serverski pristup je dobitak, ali menja ponašanje. U MariaDB su transakcije (InnoDB) centralne. Treba odlučiti gde su granice transakcija: po dijalogu, po operaciji čuvanja, po batchu. Posebno važno: dugačke transakcije i „edit-modus“ preko minuta su u Paradox-svetu česti, ali na serverskoj strani rizični (lock-ovi, deadlock-ovi, replicacioni lag). Prilagođavanje radnih navika ili UI-ja često je deo migracije.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

U B2B-okruženjima stabilnost operacija je često važnija od brzog preseka. Fazen pristup smanjuje rizik jer poslovna jedinica i IT iterativno mogu validirati rezultate.

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

U prvom koraku se gradi MariaDB-shema koja preslikava Paradox-strukturu – ali već po ciljanim principima: primarni ključevi, indeksi, odgovarajući tipovi podataka, utf8mb4, InnoDB. Paralelno se pravi reproducibilan import-proces (skripte/alati) koji se po potrebi može ponavljati. Važno je ponovljivost, jer migracija retko uspe pri prvom pokušaju.

Tipični deliverables ove etape su obično:

• Definicija sheme (DDL) verzionisana (npr. u Git)
• Lista mapiranja polja (Paradox → MariaDB) uključujući pravila konverzije
• Import-procedura sa logovanjem (broj zapisa, greške, outlieri)
• prvi validacioni izveštaji (brojevi, sume, kontrolne sume)

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

Stvarni korak modernizacije je razdvajanje od BDE. U Delphi-projektima BDE-Ablosung mit nativer Anbindung je proveren put, jer nudi moderne drajvere, transakcije, vezivanje parametara i jedinstvene komponente za različite SQL-backende. Ključno nije samo „BDE van“, već kako kod nakon toga izgleda: centralizovan pristup podacima, jasna obrada grešaka, uredni parametri umesto konkatenacije stringova.

Tipični zadaci u ovoj etapi:

• Zamena TTable/TQuery sa FireDAC-Queryjima i DataSet-ovima
• Uvođenje sloja za pristup podacima (DAL) kao osnove za kasniju Layer-3 arhitekturu
• Standardizacija transakcijskih opsega (Commit/Rollback)
• SQL-review: prilagođavanje 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 uredne deployment-pipeline-ove.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

Za kritične sisteme paralelni rad je smislen: MariaDB se podiže i ciklično (ili inkrementalno) puni, dok legacy sistem nastavlja da radi. Time poslovna jedinica može porediti izveštaje, identificirati rubne slučajeve i testirati novu platformu pod opterećenjem. Paralelni rad se može realizovati različito:

• Read-only-replika za pripremu izveštavanja/BI
• „Dual Write“ u definisanim poddomenima (samo ako je dobro kontrolisano)
• Stichtagsmigration sa više generalnih proba i jasnom cutover-checklistom

Važno je ne preceniti kompleksnost: Dual-Write zvuči atraktivno, ali je sklono greškama ako poslovna logika nije centralizovana. Često je ponovljiv stichtags-run sa dobrim validacijama na kraju ekonomičniji.

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

Nakon cutover-a počinje faza u kojoj MariaDB treba da pokaže svoje prednosti: referencijalni integritet, performansni indeksi, uredna prava, monitoring, testovi backup/restore. Tada se često prvi put jasno vide „pravi“ produkcioni opterećenja: dugi izveštaji, loše indeksirane pretrage, batch-azuriranja. Kontrolisana migracija ovu etapu eksplicitno planira, umesto da nastane kao neplanirani naknadni rad.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

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

• Alpha / Memo: VARCHAR/TEXT (sa utf8mb4), provere dužine i pravila trimovanja
• Number: INT/BIGINT/DECIMAL u zavisnosti od opsega vrednosti; oprez kod implicitnih decimala
• Date/Time: DATE/DATETIME/TIMESTAMP; jasna pravila za „0-datum“ ili NULL
• Logical: BOOLEAN odnosno TINYINT(1) sa jasnom semantom
• Currency: DECIMAL(… ,2/4) umesto float, da bi se izbegle greške zaokruživanja

Važno je ne samo prevesti tipove, već i zabeležiti poslovna pravila: Da li polje sme biti NULL? Koji default je poslovno ispravan? Koje kombinacije moraju biti jedinstvene? Iz toga proističu ograničenja i indeksi. Ta pravila su u Paradox/BDE sistemima često bila implicitna u UI-ju ili kodu – u MariaDB bi gde je smisleno trebalo da postanu eksplicitna.

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

Mnoge legacy-baze rade godinama bez referencijalnog integriteta – dok integracije, portali ili paralelni procesi ne počnu da se povezuju. Tada se kvalitet podataka pokaže kao limitirajući faktor. U MariaDB se mogu upotrebiti Foreign Keys, Unique Constraints i CHECK (zavisno o verziji/enginu) da se greške u podacima rano spreče.

Praktičan put je uvoditi integritet fazno:

• Prvo primarni ključevi i jedinstveni indeksi na ključnim objektima (kupci, artikli, dokumenti)
• Zatim Foreign Keys u stabilnim oblastima
• Za „istorijske“ tabele sa prljavim podacima: prvo čišćenje, pa ograničenja

To smanjuje rizik da cutover zakaže zbog starih nedostataka, a i značajno poboljšava ukupno stanje.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE-sistemi su često optimizovani za „brzinu fajla“: lokalni indeksi, brzi pristupi tabelama, mnogo klijentskog filtriranja. Sa MariaDB rad se prebacuje na server. To je dobro, ali zahteva uredan SQL i strategiju indeksiranja.

Typische Performance-Fallen

• SELECT * iz velikih tabela, jer je ranije „lokalno“ bilo dovoljno brzo
• Clientseitiges Filtern umesto server-side WHERE-klauzula
• Fehlende zusammengesetzte Indizes za polja pretrage (npr. mandant + status + datum)
• LIKE ‚%text%‘ bez odgovarajuće fulltext-strategije

Messbar verbessern statt „nach Gefühl“

Kontrolisana migracija rano uspostavlja merni sistem: 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 stvaraju nova ponašanja pristupa (mnogo malih zahteva, paging, endpoint-i za pretragu).

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

U Delphi-projektima tehnička modernizacija je tesno povezana sa pristupom podacima. BDE nije samo „drajver“, već kompletan stil pristupa (TTable, rad sa zapisima, navigacija, lokalni filteri). Migracija na MariaDB je pravi trenutak da se pristup konsoliduje.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Mnoge aplikacije imaju u svakom formu sopstvene upite. To slabo skaluje sa aspekta poslovne logike i sigurnosti. Dokazana promena teži:

• Centralne repository-/service-klase za ključne objekte
• Jedinstveno rukovanje greškama i transakcijama
• Parametrizovani upiti (sprečavanje SQL Injection, iskorišćavanje plan-caching-a)
• Konfigurisani connection-pool-ovi ili upravljanje konekcijama za servise

Time nastaje osnova za Layer-3 arhitekturu u kojoj su UI, poslovna logika i perzistencija jasno razdvojeni. To pomaže ne samo pri promeni baze, već i pri kasnijem razvoju ka REST-serverima ili background servisima.

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

U projektima se stalno pojavljuju ista pitanja: Koja varijanta drajvera (MySQL/MariaDB), koje SSL-opcije, koje timezone- i datum-opcije, koja Unicode podešavanja? To nisu sitnice jer direktno utiču na konzistentnost podataka (datum/vreme), sortiranje i operativnu bezbednost (TLS). Kontrolisana migracija postavlja te parametre, dokumentuje ih i testira sa realističnim podacima.

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

Cutover je projekat za sebe. Dobar cutover-plan ne opisuje samo „kada se prebaci“, već i zaštitne mere:

• Datenfreeze: Od kada se u starom sistemu više ne unose podaci? Postoje li hitni postupci?
• Finaler Import: Koliko realno traje? (Probni treninzi daju brojke.)
• Validierung: Koje provere moraju biti „zeleni“ pre puštanja (broj redova, sume, uzorci, poslovni izveštaji)?
• Rollback: Kada se prekida i kako se nastavlja?
• Kommunikation: Ko daje odobrenje? Ko je dostupan u War Room-u?

U srednjim preduzećima „rollback“ često nije tehnički već organizaciono kritičan. Zato migracija mora biti pripremljena tako da cutover nije eksperiment, već proba i proveren tok.

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

Kada MariaDB stabilno radi i BDE-zamenа je uredno izvedena, otvaraju se nove opcije: REST-API-ji za eksterne sisteme, pozadinska obrada kao Windows- ili Linux-servisi, razdvajanje UI-ja i poslovne logike i perspektivno multiplatform klijenti. Čest sledeći korak je izvlačenje poslovne logike iz desktop aplikacije kako bi integracije (ERP/DMS/CRM) i portali bili servisirani kontrolisano.

Važno: REST-Server nije „dodatni sloj“, već arhitektonska odluka. Ko je već konsolidovao pristup podacima, validacije i ovlašćenja u servisima/repository-ima, lakše će iz toga razviti 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 obimi podataka (veličine tabela, rast, koncepti arhiviranja)?
• Koji izveštaji moraju biti 1:1 identični, koji smeju biti unapređeni?
• Koje integracije zavise od sistema (fajl-exporti, ODBC, Office, štampačke rute)?
• Postoji li multi-mandantnost, i ako da: kako je danas predstavljena?
• Koji operativni zahtevi važe (backup- Prozori, vreme restore-a, prava, audit)?

Ta pojašnjenja nisu birokracija, već sprečavaju da migracija bude „tehnički gotova“, a poslovno neprihvaćena.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

Kontrolisana migracija iz Paradox-a i BDE u MariaDB znači modernizaciju aplikacije kao celokupnog sistema: model podataka, SQL, transakcije, skupovi karaktera, sloj pristupa i operativni procesi. Ko promenu tretira kao puku izvoz podataka, obično dobije iste probleme koje je želeo da eliminiše – samo na novom serveru.

Fazni pristup sa reproducibilnim importom, urednim mapiranjem polja, ranom validacijom i jasnom BDE-Ablösung (npr. preko FireDAC) gradi za to stabilnu osnovu: za višekorisnički rad, integracije, servise i naredne korake u Delphi Modernisierung.

Ako želite da vašu migraciju planiramo stručno i bez prekida u radu, rado ćemo razgovarati o polaznoj tački, rizicima i realističnom planu faza: https://net-base-software-gmbh.de/kontakt/