Paradox og BDE flytja á stýrðan hátt yfir í MariaDB

Mörg Delphi-sérforrit voru upphaflega byggð á Paradox-töflum og Borland Database Engine (BDE), því það var þá hagnýtur staðall: staðbundið, fljótt tilbúið til notkunar og með litla innviði. Í reynd eru þessi kerfi oft enn í framleiðslu – þar með talin skýrslugerð, merkjaprentun, inn-/útflutningur, lotuvinnsla, sögutöflur og sérsniðin rökfræði sem hefur smám saman „vinnið sig inn“ í gagnaaðgengi á árum saman. Þess vegna er flutningur ekki einungis útflutningur gagna, heldur stýrð endurhönnun: gagnalíkan, SQL-hegðun, aukaverkanir í kóða og rekstrarferlar verða að skoða saman.

MariaDB er oft mjög gott val sem markvettvangur þegar um ræðir traustan fjölnotendarekstur, skýrar transaktionir, miðlægar afritanir, eftirmyndun, skýra réttindastýringu og tengimöguleika fyrir vefgáttir, þjónustur eða REST-API. Áskorunin er sjaldnast uppsetning gagnagrunnsins – hinn raunverulegi kostnaður liggur í öruggri flutningsleið: Hvernig verða töflur, vísar, aðallyklar, stafasett, dagsetningarreitir, „tóm“ gildi og tilvísanir rétt flutt án þess að fagleg rökfræði brotni í rekstri?

Þessi grein lýsir prófuðum vinnubrögðum til að flytja Paradox og BDE stýrt yfir í MariaDB: tæknilega traust, stigvaxandi og með áherslu á stöðugleika. Markmiðið er að skapa burðarþolanlegan grunn fyrir frekari nútímavæðingu – til dæmis BDE-afnám, umskipti í BDE-afnám með innbyggðri tengingu, skýra Layer-3 arkitektúr, REST-þjóna og fjölpallaviðskiptavini.

Hvers vegna er Paradox/BDE-flutningur meira en einfaldur gagnagrunnsskipti

Paradox sem skráarform og BDE sem aðgangslag mynda heildarkerfi með sérkennum sem ekki er æskilegt að endurgera 1:1 í MariaDB. Algeng einkenni í daglegum rekstri eru:

• Ósýnileg háðtengsl: SQL-fyrirmæli eru dreifð (Forms, DataModules, Reports, dynamic String-SQL), oft án miðstýrðrar governance.
• Hegðun „eftir tilfinningu“: Sumir síur, röðunar- eða join-sambönd virka af tilviljun því Paradox/BDE er umburðarlynd eða gerir duldar tegundarbreytingar.
• Takmörkun fjölnotendarekstrar: Skrábundnar læsingar, frammistöðuvandamál yfir net, læsingavandamál við vaxandi gagnamagn.
• Viðhaldshættur: BDE-háð, gamlir driver-ar, erfið útbreiðsla á nútíma Windows-útgáfum, 64‑bit/ARM64-áskoranir.

Stýrður flutningur tekur þessi atriði fremur en sem aukaverkun: MariaDB verður ekki bara „nýr gagnagrunnur“, heldur tækifæri til að aflaga gagnaaðgengisstig, styrkja faglega heilleika og bæta samhæfi við viðmót og þjónustur.

Markmynd: MariaDB sem stöðugur gagnagrunnur fyrir skrifborð, þjónustur og gáttir

Gagnleg markmynd fyrir B2B-sérforrit byggir yfirleitt á þremur lögum:

• Gagnagrunnur (MariaDB): samkvæm gagnageymsla, vísar/índex, constraints, transaktionir, notendur/hlutverk, afrit.
• Fagleg rökfræði (Server/Services): staðfestingar, vinnuferlar, innflutningsþjónar, tímastillir, tengi. Valfrjálst sem REST-þjóni, Windows- eða Linux-þjónum.
• Viðmót (VCL/FMX/Web): notendaviðmót, skýrslur, offline-hlutar, samþættingar. Æskilegt með skýrum samningum við faglegu rökfræði.

Eftir upphafsstöðu þarf ekki allt að vera útfært strax. En flutningurinn ætti að vera skipulagður þannig að vegurinn að hreinni arkitektúr verði ekki lokaður. Sá sem afritar í dag aðeins töflur og skrifar aftur „beinlínis“ úr hverju formi á gagnagrunninn, hefur vissulega fært MariaDB inn en hitt raunverulega áhættuna stendur áfram.

Staðaúttekt: Hvað þarf raunverulega að flytja

Í byrjun stendur umfangsreikningur sem nær út fyrir „hversu margar töflur“. Í Paradox/BDE-verkefnum er algengt að gagnagrunnurinn sé aðeins hluti af sannleikanum. Mikilvæg atriði:

1) Töflur, vísar, „pseudo-lyklar“

Oft vantar raunverulega Primary Keys. Í staðinn eru samsetningar reita, reiknandi númer án ótvíræðs constraints eða „key“-reitir sem eru viðhaldnir í forritinu. Fyrir MariaDB þurfa þetta að verða ótvíræðir, traustir lyklar – ella verða transaktionir og vísað faglegt heilleika aðeins takmarkaðir.

2) Fyrirspurnir, dynamique SQL-bútar, skýrslur

BDE notar eftir íhlutun mismunandi SQL-díalekt og leyfir stundum „kreatívar“ yfirlýsingar. Skýrslugerðareiningar (jafnvel eldri) innihalda oft sínar eigin SQL-skilgreiningar. Flutningur þarf að finna og flokka þessi uppsprettu: kjarnafyrirspurnir sem eru gagnrýnar, sjaldan notaðar úttektir, sérinnflutningar.

3) Stafasett og sérstafir (Umlaute, ISO/ANSI, Unicode)

Margar Paradox-umsóknir eru sögulega ANSI-bólgnar. Ef Delphi-umsóknin sjálf var seinna færð yfir í Unicode getur myndast blandað umhverfi: gögn liggja í gömlu encoding, UI er Unicode, útflutningar gera ráð fyrir Windows-1252. MariaDB þarf skýra stefnu hér (venjulega utf8mb4), þar með talið hreina umbreytingu og prófanir á „ósýnilegum“ villum (samanburðir, röðun, Trim/Pad, sérstafir).

4) „Tóm“ gildi, NULL-logic og dagsetningarreitir

Paradox/BDE þekkir ýmsa sértilvik: tómir strigar í stað NULL, 0-dagsetningar, „tóm“ timestamps, sjálfgefna gildi sem myndast í UI. MariaDB gerir skýrari grein milli NULL og tómra reita. Það hefur áhrif á WHERE-klausur, samantektir og útreikninga. Þessar mismununir verða metnar fyrir hverja töflu/reit.

5) Hliðarafurðir: session-töflur, staðbundin stilling, cache

Oft eru í Paradox-uppsetningu staðbundnar töflur fyrir milliniðurstöður, útflutningsbuffra, notendalögun eða parametrar. Sumt á áfram að vera staðbundið (t.d. UI-uppsetningar), annað ætti að miðstýra (t.d. vinnuferlar, stöður, logg). Flutningur er tækifæri til að hreinsa þessa flokka.

Steinarnir: algengar tæknilegar mismunir við Paradox/BDE

Til að gera flutningsverkefni áætlunarhæft er gagnlegt að takast á við endurtekna muninn skýrt.

SQL-díalekt og rekstraraðilar

BDE/Paradox-SQL er ekki eins og MySQL/MariaDB-SQL. Mismunur kemur fram m.a. í dagsetningaföllum, strengföllum, ytri joinum (sögulega), Like-/mynsturlógík og duldum tegundarbreytingum. Stýrður aðgangur skiptir „virkar núna“ út fyrir skýrar reglur: Hvaða yfirlýsingar eru fluttar, hvaða eru endurskrifaðar, hvaða eru huldir í Views/Stored Procedures (ef það er réttmætt)?

Raðun og collation

Í Paradox eru röðunarreglur og case-sensitivity oft aðrar en í MariaDB, sér í lagi fyrir úmlaut. Í MariaDB ræður collation (t.d. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) um samanburð og röðun. Þetta er ekki fræðilegt atriði: það hefur áhrif á afritun, leitaraðgerðir og hegðun Unique-constraints.

Autoincrement og númerakerfi

Paradox hefur autoincrement-reiti, en forrit nota gjarnan eigin númerakerfi (fylgiskrár, pöntunarnúmer) með sérstöku regluverki. Í MariaDB ætti aðgreining að vera skýr:

• Tæknilegur aðallykill: AUTO_INCREMENT (eða UUID, eftir arkitektúr) fyrir tengsl.
• Faglegt númer: sérstakt númerakerfi með transaktionavernd, mögulega per viðskiptavin/ tímabil.

Sá sem reynir að misnota faglegt númer sem tæknilegan lykil mun rekast á dýrar umbætur síðar.

Læsingar og transaktionir

Skriðið frá skrábundnum aðgangi yfir í raunverulegan þjón breytir hegðun. Í MariaDB eru transaktionir (InnoDB) grunnatriði. Það þarf að taka afstöðu hvar transaktionamörk liggja: per dialog, per vistun eða per lotu. Sérstaklega mikilvægt: löng transaktion (mínútur af „edit-mode“) eru algeng í Paradox-heimum en gagnrýnar á þjónsviði (lásar, deadlocks, replíkuleiðni). Hér er oft nauðsynlegt að aðlaga vinnubrögð eða UI sem hluta af flutningnum.

Aðferðarháttur: stýrður flutningsferill í stigum í stað Big Bang

Í B2B-umhverfi skiptir rekstrarstöðugleiki oft meira máli en snögg færsla. Stigvaxandi flutningsleið dregur úr áhættu því fagdeildir og IT geta yfirfarið og vottað í lotum.

Etappa 1: Gagnalíkan-flutningur með mapping, án kóðabreytinga

Í fyrsta skrefi er MariaDB-skipulag byggt sem endurmótun á Paradox-uppbyggingu – en með markreglum: aðallyklar, vísar, viðeigandi gagnagerðir, utf8mb4, InnoDB. Samhliða er byggður upp endurteknanlegur innflutningsferill (skript/tól) sem hægt er að keyra aftur og aftur. Mikilvægt er endurtekningarhæfni því flutningur er sjaldan fullgerður í fyrsta keyrslu.

Afurðir þessa áfanga eru yfirleitt:

• Schema-skilgreining (DDL) í útgáfustýringu (t.d. Git)
• Reitapörun (Paradox → MariaDB) með umbreytingareglum
• Innflutningsferli með skráningu (fjöldi færslna, villur, útbrygði)
• Fyrstu sannprófanir (counts, summur, checksum)

Etappa 2: BDE-afnám í gagnaaðgangi (t.d. með FireDAC)

Lykilskrefið í nútímavæðingu er að losa forritið við BDE. Í Delphi-verkefnum er BDE-Ablosung mit nativer Anbindung oft notað vegna nútímadrivera, transaktiona, parameterbinding og sameiginlegra íhluta fyrir mismunandi SQL-backenda. Mikilvægast er ekki að „fjarða BDE“, heldur hvernig kóðinn lítur út eftir: miðstýrður gagnaaðgangur, skýr villumeðhöndlun og hreinar parametrar í stað strengsamruna.

Algeng verkefni í þessum áfanga:

• Skipta út TTable/TQuery fyrir FireDAC-Queries og DataSets
• Innleiða Data-Access-lag (DAL) sem grundvöll fyrir síðar Layer-3-arkitektúr
• Staðfesta transaktiona-scope (Commit/Rollback)
• SQL-endurskoðun: díalektun, parametra, paging, joins

Ef umsóknin á að moderniserast til lengri tíma er þetta skref oft mikilvægara en hreinn gagnaflutningur. Það skapar tæknilegt frelsi fyrir 64‑bit, nútíma Windows-útgáfur og hreinar deployment-pípur.

Etappa 3: Síðlaus rekstur og fagleg vottaun án rekstrartruflunar

Fyrir viðkvæm kerfi er gagnlegt að reka kerfin samtímis: MariaDB er uppsett og fyllt sígildum eða stigvaxandi hætti, meðan gamla kerfið heldur áfram. Þannig getur fagdeild borið saman úttak, fundið jaðartilvik og prófað nýja vettvanginn undir álagi. Samhliða reksturinn getur verið útfærður með mismunandi hætti:

• Read-only-replik fyrir skýrslugerð/BI-undirbúning
• „Dual Write“ í afmörkuðum hlutum (aðeins ef vel er stjórnað)
• Stigadreifður stigtökuflutningur með mörgum þurrkeyrslum og skýru Cutover-checklista

Mikilvægt er að ekki flækja ferlið of mikið: Dual-Write er laðandi en áhættusamt ef fagleg rökfræði er ekki miðstöðvuð. Oft er endurtekin stigtökuflutningur með góðri sannprófun hagkvæmari.

Etappa 4: Hagræðing, heilleiki, frammistaða, rekstrarferlar

Eftir Cutover byrjar sá áfangi þar sem MariaDB á að sýna kosti sína: vísaður faglegi heilleiki, hraðvirkir vísar, skýr réttindaskipan, eftirlit, Backup/Restore-próf. Hér birtast oft „raunveruleg“ framleiðsluálög: langar skýrslur, illa vísuð leit, lotubreytur. Stýrður flutningur innifelur þennan áfanga sérstaklega, í stað þess að láta hann verða óskipulagt eftirverk.

Gagnagerðir og mappping: frá Paradox til MariaDB án upplýsingataps

Reitapörunin er kjarni flutningsins. Algengar samsvörun (einungis sýnishorn) eru:

• Alpha / Memo: VARCHAR/TEXT (með utf8mb4), lengdarstýring og Trim-reglur
• Number: INT/BIGINT/DECIMAL eftir gildisviði; varúð við duldar aukastafir
• Date/Time: DATE/DATETIME/TIMESTAMP; skýrar reglur fyrir „0-dagsetningu“ eða NULL
• Logical: BOOLEAN eða TINYINT(1) með ótvíræðri merkingu
• Currency: DECIMAL(…,2/4) í stað Float til að forðast leiðréttingavillur

Mikilvægt er ekki aðeins að þýða gagnagerðir heldur einnig að festa faglegar reglur: Má reiturinn vera NULL? Hvaða sjálfgefnu gildi eru faglega rétt? Hvaða samsetningar verða ótvíræður? Úr þessu koma constraints og vísar. Þessar reglur voru í Paradox/BDE oft falið í UI eða kóða – í MariaDB ætti, þar sem við á, að gera þær skýrar.

Heilleiki: Að fylgja eftir aðallyklum, fremri lykla og einstökum vísum

Margar legacy-gagnagrunna hafa starfað árum saman án vísaðs faglegs heilleika – þar til samþættingar, gáttir eða samhliða ferlar bætast við. Þá verða gögnin takmarkandi þáttur. Í MariaDB er hægt að innleiða Foreign Keys, Unique Constraints og Checks (eftir útgáfu/engin) til að stöðva gögnavillu snemma.

Hagnýt leið er að innleiða heilleika stigvaxandi:

• Fyrst aðallyklar og einstakir vísar á kjarnaobjekt (viðskiptavinir, vörur, skjöl)
• Síðan Foreign Keys á stöðugum svæðum
• Fyrir „sögutöflur“ með rusladót: fyrst hreinsun, síðan constraints

Þetta minnkar líkur á því að Cutover bregðist vegna gamalla galla og bætir samtímis heildarstöðu verulega.

Frammistaða í gagnreyndri notkun: hvað breytist með MariaDB

Paradox/BDE-kerfi voru gjarnan fínstillt fyrir „skrárhraða“: staðbundnir vísar, hraðar töfluaðgerðir, mikið client-side filter. Með MariaDB færist vinnan á þjóninn. Það er jákvætt, en krefst hreins SQL- og vísastefnu.

Algengar frammistöðufallar

• SELECT * úr stórum töflum, því áður var staðbundið nóg
• Client-side filtering í stað server-side WHERE-klausla
• Skortur á samsettum vísum fyrir leitaflöt (t.d. mandant + status + date)
• LIKE ‚%text%‘ án viðeigandi fulltext-stefnu

Hægt að bæta mælanlega í stað „eftir tilfinningu“

Stýrður flutningur innleiðir snemma mælipunkta: Slow Query Log, Explain-greiningar, endurtekna álagaprufu. Þetta er sérstaklega mikilvægt ef eftir flutning er stefnt að nýjum íhlutum, t.d. REST-þjóni eða Kundagátt, sem breyta aðgangsmynstri (mörg smáfyrirspurnir, paging, leit).

Delphi-sértækt: BDE-afnám, FireDAC og hreinar aðgangslög

Í Delphi-verkefnum er tæknileg nútímavæðing þétt tengd gagnaaðgangi. BDE er ekki bara „driver“, heldur heill aðgangsstíll (TTable, færsluháð, sigling, staðbundin síun). Flutningur yfir í MariaDB er rétti tíminn til að samræma aðganginn.

Frá „DataSets alls staðar“ í stjórnaðan gagnaaðgang

Mörg forrit hafa sérstakar fyrirspurnir í hverju formi. Þetta skalar illa faglega og öryggislega. Reynd lausn er að breyta í þessa átt:

• Miðstýrðar Repository-/Service-klasur fyrir kjarnaobjekt
• Einingleg villa- og transaktionameðhöndlun
• Parametriserðar fyrirspurnir (til að koma í veg fyrir SQL Injection, nota plan-caching)
• Stjórnanlegir connection-poolar eða connection-management fyrir þjónustur

Þetta myndar grundvöll fyrir Layer-3-arkitektúr, þar sem UI, faglega rökfræði og gagnageymsla eru skýrlega aðskilin. Það hjálpar ekki aðeins við gagnagrunnsskipti heldur einnig við frekari uppbyggingu í átt að REST-þjónum eða bakgrunnsþjónustum.

MariaDB-tenging með FireDAC: hvað þarf venjulega að afklára

Í verkefnum koma alltaf upp sömu spurningarnar: Hvaða driver-útgáfa (MySQL/MariaDB), hvaða SSL-opsjónir, timezone- og dagsetningastillingar, hvaða Unicode-uppsetning? Þetta eru ekki smáatriði því þau hafa bein áhrif á gagnasamkvæmni (dagsetning/klukka), röðun og rekstraröryggi (TLS). Stýrður flutningur setur þessa parametra, skjalfestar þá og prófar með raungögnum.

Cutover-plan: Stigdagur, gagnafreeze, rollback – án óvissu

Cutover er verkefni í sjálfu sér. Góð áætlun lýsir ekki aðeins „hvenær færum við yfir“ heldur einnig verndarráðstöfunum:

• Gagnafreeze: Frá hvaða tímapunkti eru engin ný gögn skráð í gamla kerfið? Eru neyðarferlar til?
• Endanlegur innflutningur: Hversu langan tíma tekur hann raunhæft? (Þurrkeyrslur gefa tölur.)
• Staðfesting: Hvaða athuganir þurfa að vera grænar fyrir útskrift (counts, summur, úrtak, faglegar skýrslur)?
• Rollback: Hvenær er hætt við og hvernig er þá haldið áfram?
• Samskipti: Hver gefur út leyfi? Hver er tiltækur í stjórnherbergi?

Í smærri fyrirtækjum er „rollback“ oft frekar skipulagslegt vandamál en tæknilegt. Því þarf flutningur að vera undirbúinn þannig að Cutover sé ekki tilraun heldur æfður ferill.

Eftir flutning: Grunnur fyrir REST, þjónustur og fjölpallakerfi

Þegar MariaDB starfar traust og BDE-afnám er rétt framkvæmt, opnast nýir valkostir: REST-API fyrir ytri kerfi, bakgrunnsvinnsla sem Windows- eða Linux-þjónustur, aftenging UI og faglegs lags og að lokum fjölpallaviðskiptavinir. Algeng næsta skref er að draga faglega rökfræði út úr skrifborðsforritinu til að þjóna samþættingum (ERP/DMS/CRM) og gáttum á öruggari hátt.

Það er mikilvægt að átta sig á því: REST-þjónn er ekki „auknalag“, heldur arkitektúrleg ákvörðun. Sá sem hefur þegar samræmt gagnaaðgang, staðfestingar og réttindi í þjónustum/Repository getur hraðað þróun á traustum API-um.

Verklegs athugasemdir: Hvað ætti að afklára fyrir verkefnissetningu

• Hvaða einingar eru viðskiptagreindar og verða að keyra örugglega á Cutover-degi?
• Hvernig eru raunveruleg gagnamagn (töflustærðir, vöxtur, geymslukerfi)?
• Hversu mörg skýrslur þurfa að vera 1:1 eins og áður, og hverjar má bæta?
• Hvaða samþættingar styðja kerfið (skráaútflutningar, ODBC, Office, prentslóðir)?
• Er marggreinaskipting (Mandantenfähigkeit) til staðar, og ef já: hvernig er hún nú útfærð?
• Hvaða rekstrarkröfur gilda (backup-gluggi, restore-tími, réttindi, audit)?

Þessar afklaranir eru ekki bókhald heldur koma í veg fyrir að flutningur verði „tæknilega kláraður“ en faglega óvottaður.

Niðurstaða: Stýrður flutningur gerir áhættu áætlanlega

Það að flytja Paradox og BDE stýrt yfir í MariaDB þýðir að nútímavæða heildarkerfið: gagnalíkan, SQL, transaktionir, stafasett, aðgangslag og rekstrarferlar. Sá sem lítur á flutning eingöngu sem gagnaflutning fær oft nákvæmlega þær vandamál sem hann ætlaði að losna við – á nýjum þjón.

Stigvaxið ferli með endurteknanlegum innflutningi, hreinu reitapari, snemma staðfestingum og skýrri BDE-afnám (t.d. með FireDAC) skapar aftur á móti traustan grunn: fyrir fjölnotendarekstur, samþættingar, þjónustur og næstu skref í Delphi Modernisierung.

Ef þið viljið skipuleggja flutning faglega og án rekstrartruflana ræðum við gjarnan upphafsstöðu, áhættu og raunhæfan stigaflöt: https://net-base-software-gmbh.de/kontakt/