Kontrollert migrering av Paradox og BDE til MariaDB

Mange Delphi-fagsystem har vorte bygd med Paradox-tabellar og Borland Database Engine (BDE), fordi det tidlegare var ein pragmatisk standard: lokal, rask å ta i bruk, og med låg krav til infrastruktur. I praksis går desse systema ofte framleis i produksjon – inklusive rapportering, etikettutskrift, import/eksport, batch-jobbar, historietabellar og spesiell logikk som gjennom åra har «skriven seg inn» i dataåtkomsten. Difor er ein migrasjon ikkje berre ein eksport av data, men ein kontrollert ombygging: datamodell, SQL-åtferd, sideverknadar i koden og driftsprosessar må vurderast samla.

MariaDB er ofte eit svært godt mål når målet er robust fleirbrukardrift, pålitelege transaksjonar, sentrale backup-ar, replikasjon, klår rettsstyring og tilknyting til web-portalar, tenester eller REST-APIar. Utfordringa ligg sjeldan i sjølve databaseinstallasjonen – den egentlege innsatsen handlar om ein sikker migrasjonsveg: Korleis overfører vi tabellar, indeksar, primærnøklar, teiknsett, datofelt, «tomme» verdiar og referansar korrekt, utan at faglogikken bryt i den daglege drifta?

Denne artikkelen skildrar ein prøvd framgangsmåte for å migrere Paradox og BDE kontrollert til MariaDB: teknisk fundert, trinnvis og med fokus på stabilitet. Målet er eit solid grunnlag for vidare moderniseringstiltak – til dømes BDE-utskifting, overgang til BDE-Ablösung mit nativer Anbindung, klar Layer-3 arkitektur, REST-server og plattformnøytrale klientar.

Kvifor Paradox/BDE-migrasjon er meir enn eit databaseskifte

Paradox som filformat og BDE som tilgangslag utgjer eit heilskapssytem med eigenskapar ein ikkje bør kopiere 1:1 i MariaDB. Typiske symptom i dagleg bruk er:

• Utydelege avhengigheiter: SQL-setningar ligg spreidd (Forms, DataModules, Reports, dynamiske streng-SQL), ofte utan sentral styring.
• «Følelsesbasert» åtferd: Visse filtreringar, sorteringar eller joins fungerer tilfeldig fordi Paradox/BDE er tolerante eller implicit konverterer typar.
• Fleirbrukargrenser: Filbaserte sperrar, ytelsesproblem i nettverket, locking-problem ved aukande datamengde.
• Vedlikehaldsrisikoar: BDE-avhengigheiter, gamle drivarar, vanskeleg deploy på moderne Windows-versjonar, 64‑Bit/ARM64-tema.

Ein kontrollert migrasjon tek desse punkta som målsetjingar, ikkje som tilfeldige bi-effektar. MariaDB blir då ikkje berre «ein ny database», men ei moglegheit til å løyse opp dataåtkomstlaget, auke fagleg integritet og opprette klare grensesnitt.

Målbilete: MariaDB som stabil databasis for desktop, tenester og portal

Eit rimeleg målbilete for B2B-fagsystem består vanlegvis av tre lag:

• Database (MariaDB): konsekvent datalagring, indeksar, constraints, transaksjonar, brukarar/roller, backup.
• Faglogikk (Server/Tenester): valideringar, arbeidsflyt, importer, scheduler, grensesnitt. Valfritt som REST-server, Windows- eller Linux-tenester.
• Klientar (VCL/FMX/Web): brukargrensesnitt, rapportar, offline-komponentar, integrasjonar. Ideelt med klare kontraktar mot faglogikken.

Avhengig av utgangspunktet treng ikkje alt å implementerast med ein gong. Men migrasjonen bør planleggast slik at ho ikkje sperrar vegen mot ei rein arkitektur. Dei som i dag berre kopierar tabellar og morgonen etter igjen skriv «direkte» frå kvart skjema til databasen, har kanskje MariaDB innført – men dei underliggjande risikoane er framleis til stades.

Gjennomgang: Kva må faktisk migrerast

Fyrst må ein gjere eit inventar som går utover «kor mange tabellar». I Paradox/BDE-prosjekt er det vanleg at databasen berre er ein del av sanninga. Viktige punkt:

1) Tabellar, indeksar, «pseudo-nøklar»

Ofte manglar sanne Primary Keys. I staden finst kombinasjonar av felt, løpande nummer utan entydig constraint eller «Key»-felt som blir vedlikehaldne i applikasjonen. For MariaDB må desse bli entydige, robuste nøklar – elles verkar transaksjonar og referansiell integritet berre avgrensa.

2) Forespørsler, dynamiske SQL-bitar, rapportar

BDE brukar avhengig av komponent ulike SQL-dialektar og tolererer kreative statement. Rapportkomponentar (inkludert eldre) inneheld ofte eigne SQL-definisjonar. Ein migrasjon må finne og kategorisere desse kjeldene: kritiske kjerne-queries, sjeldan brukte utvalsrapportar, spesialimportar.

3) Teiknsett og spesialteikn (umlautar, ISO/ANSI, Unicode)

Mange Paradox-applikasjonar er historisk ANSI-baserte. Dersom Delphi-applikasjonen tidlegare er blitt sett om til Unicode, oppstår blandingsbilete: data ligg i gamalt encoding, UI er Unicode, eksportar forventar Windows-1252. MariaDB bør ha eit tydeleg konsept her (vanlegvis utf8mb4), inklusive rein konvertering og testar for «usynlege» feil (samanlikningar, sortering, Trim/Pad, spesialteikn).

4) «Tomme» verdiar, NULL-logikk og datofelt

Paradox/BDE kjenner fleire spesialtilfelle: tomme strengar i staden for NULL, 0-datoar, «tomme» tidsstempel, defaultverdiar skapte i UI. MariaDB skil strengt mellom NULL og tomt. Det påverkar WHERE-klausular, aggregeringar og berekningar. Desse skilnadene må vurderast tabell- og feltvis.

5) Sideartefakt: session-tabellar, lokal konfigurasjon, cache

Ofte finst det lokale tabellar i Paradox-strukturen for mellombels resultat, eksportbuffarar, brukaroppsett eller parameter. Nokre ting høyrer framleis heime lokalt (t.d. UI-oppsett), andre bør sentraliserast (t.d. arbeidsoppgåver, status, loggar). Ein migrasjon er ein moglegheit til å skilje desse kategoriane tydeleg.

Fallgruver ved Paradox/BDE: typiske tekniske skilnader

For at migrasjonen skal bli planbar, løner det seg å adressere dei gjentakande skilnadene eksplisitt.

SQL-dialekt og operatorar

BDE/Paradox-SQL er ikkje identisk med MySQL/MariaDB-SQL. Skilnader opptrer mellom anna i datofunksjonar, strengfunksjonar, outer joins (historisk), LIKE/maskelogikk og ved implisitt typkonvertering. Ein kontrollert strategi erstattar «det fungerer» med klare reglar: Kva statement vert portert, kva vert skrive om med vilje, og kva vert kapsla inn i Views/Stored Procedures (om det er hensiktsmessig)?

Sortering og collasjon

I Paradox er sorteringsrekkefølgje og case-sensitivitet ofte ulikt MariaDB, særleg for umlautar. I MariaDB avgjer collationen (t.d. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) samanlikning og sortering. Dette er ikkje akademisk: det påverkar deduplisering, søkefunksjonar og åtferd for Unique-constraints.

Autoincrement og nummerområde

Paradox har autoincrement-felt, men applikasjonar brukar ofte eigne nummerområde (dokumentnummer, ordrenummer) med spesiallogikk. I MariaDB bør ein skilje klart:

• Teknisk primærnøkkel: AUTO_INCREMENT (eller UUID, avhengig av arkitektur) for relasjonar.
• Fagleg nummer: eige nummerområde med transaksjonsvern, eventuelt per klient/periode.

Å misbruke eit fagleg nummer som teknisk nøkkel fører ofte til kostbare ombyggingar seinare.

Locking og transaksjonar

Spranget frå filbasert tilgang til ein ekte server er ein gevinst, men endrar åtferda. I MariaDB er transaksjonar (InnoDB) sentrale. Ein må avgjere kvar transaksjonsgrensene skal liggje: per dialog, per lagringsoperasjon eller per batch. Særleg viktig: lange transaksjonar og «edit-modus» over fleire minutt er vanleg i Paradox-verda, men kritisk på serversida (locks, deadlocks, replikasjonslag). Her er tilpassing av arbeidsmåte eller UI ofte eine del av migrasjonen.

Vekemodell: kontrollert migrasjon i etappar i staden for Big Bang

I B2B-miljø er driftsstabilitet oftare viktigare enn eit raskt avbrot. Ein gradvis migrasjonsveg reduserer risiko fordi fagavdelinga og IT kan validere iterativt.

Etappe 1: Datamodell-overføring med mapping, utan kodeombygging

I første steg byggjer ein opp eit MariaDB-skjema som speglar Paradox-strukturen – men allereie etter målprinsipp: Primary Keys, indeksar, føremålstenlege datatypar, utf8mb4, InnoDB. Parallelt vert det laga ein replikerbar importprosess (skript/verkty) som kan køyrast om att ved behov. Viktig her er repetisjonsbarheit, fordi ein migrasjon aldri er «ferdig» på første køyring.

Leveransen i denne etappen er vanlegvis:

• Versjonert skjema-definisjon (DDL) (t.d. i Git)
• Feltskjemaliste (Paradox → MariaDB) inkl. konverteringsreglar
• Importprosedyre med logging (antall postar, feil, avvik)
• Fyrste valideringsrapportar (counts, summasjonar, checksums)

Etappe 2: BDE-utskifting i dataåtkomst (t.d. med FireDAC)

Det reelle moderniseringstrinnet er å løfte seg frå BDE. I Delphi-prosjekt er BDE-Ablosung mit nativer Anbindung eit vanleg val fordi det gir moderne drivarar, transaksjonar, parameterbinding og einsarta komponentar for ulike SQL-backendar. Det avgjerande er ikkje berre «fjerne BDE», men korleis koden framstår etterpå: sentralisert dataåtkomst, klår feilhandsaming, rein parameterbruk i staden for streng-konkatenasjon.

Typiske oppgåver i denne etappen:

• Erstatte TTable/TQuery med FireDAC-Queries og DataSets
• Innføre eit Data-Access-lag (DAL) som basis for seinare Layer-3 arkitektur
• Standardisere transaksjon-scope (Commit/Rollback)
• SQL-gjennomgang: dialekttilpassing, parameter, paging, joins

Om applikasjonen skal moderniserast på lang sikt, er dette ofte viktigare enn sjølve datamigrasjonen. Det gir teknisk fridom for 64‑Bit, moderne Windows-versjonar og ryddige deploy-pipelines.

Etappe 3: Parallell drift og fagleg godkjenning utan driftsbrot

For kritiske system er parallell drift fornuftig: MariaDB sett opp og fylt syklisk (eller inkrementelt) medan gamlesystemet held fram. Dette gir fagavdelinga moglegheit til å samanlikne rapportar, identifisere randtilfelle og teste ny plattform under belastning. Parallell drift kan gjennomførast på ulike måtar:

• Read-only-replika for rapportering/BI-forberedelse
• «Dual Write» i definerte delområde (berre om dette er godt kontrollert)
• Stichtagsmigration med fleire tørrkøyringar og klår cutover-sjekkliste

Viktig er å ikkje overkomplisere: Dual-Write verkar attraktivt, men er feiltanførelsesauke om faglogikken ikkje er sentralisert. Ofte er ein repetibel stichtagskøyring med god validering økonomisk meir lønsam.

Etappe 4: Optimalisering, integritet, ytelse, driftsprosessar

Etter cutover byrjar fasen der MariaDB skal spele sine styrkar: referansiell integritet, effektive indeksar, ryddige rettar, overvaking, backup/restore-testar. Då viser ofte dei verkelege produksjonsbelastningane seg: lange rapportar, dårleg indekserte søkeskjema, batch-oppdateringar. Ein kontrollert migrasjon planlegg denne etappen eksplisitt i staden for å la han bli uplanlagt etterslep.

Datatypar og mapping: frå Paradox til MariaDB utan informasjonsbrot

Feltskjemet er kjernen i migrasjonen. Typiske tilordningar (forenkla) er:

• Alpha / Memo: VARCHAR/TEXT (med utf8mb4), lengdevalidering og Trim-reglar
• Number: INT/BIGINT/DECIMAL etter verdiområde; varsamt med implisitte desimalar
• Date/Time: DATE/DATETIME/TIMESTAMP; klare reglar for «0-dato» vs. NULL
• Logical: BOOLEAN eller TINYINT(1) med entydig semantikk
• Currency: DECIMAL(…,2/4) i staden for Float for å unngå avrundingsfeil

Viktig er ikkje berre å oversette datatypar, men også å nedteikne fagreglar: Kan eit felt vere NULL? Kva defaultverdiar er fagleg riktige? Kva kombinasjonar må vere unike? Frå dette følgjer constraints og indeksar. Desse reglane var ofte implisitte i Paradox/BDE-systemet via UI eller kode – i MariaDB bør dei, der det er hensiktsmessig, bli eksplisitte.

Integritet: Primary Keys, Foreign Keys og unike indeksar

Mange legacy-databasar har fungert i årevis utan referansiell integritet – til integrasjonar, portal eller parallelle prosessar kjem til. Då blir datakvalitet snart ei avgrensande flaskehals. I MariaDB kan ein innføre Foreign Keys, Unique Constraints og CHECKs (avhengig av versjon/engine) for å fange dataproblem tidleg.

Eit praktisk framlegg er å innføre integritet trinnvis:

• Fyrst Primary Keys og unike indeksar på kjerneobjekt (kunde, artikel, dokument)
• Særleg deretter Foreign Keys i dei stabile områda
• For «historiske» tabellar med dataskrap: fyrst rydding, deretter constraints

Dette reduserer risikoen for at cutover feilar på grunn av gamle restar, samtidig som den totale tilstanden betrar seg vesentleg.

Ytelse i praksis: kva endrar seg med MariaDB

Paradox/BDE-system er ofte optimaliserte for «fil-hastigheit»: lokale indeksar, raske tabelltilgangar, mykje klient-side filtrering. Med MariaDB flytt arbeidet til serveren. Det er positivt, men krev ryddig SQL- og indeksstrategi.

Typiske ytelsesfeller

• SELECT * frå store tabellar fordi det tidlegare var raskt lokalt
• Klient-side filtrering i staden for server-side WHERE-klausular
• Manglande samansette indeksar for søkefelt (t.d. tenant + status + dato)
• LIKE ‚%text%‘ utan eigna fulltekststrategi

Måleleg forbetring framfor «etter kjensle»

Ein kontrollert migrasjon etablerer tidleg målepunkt: Slow Query Log, Explain-analyse, reproduksjonbare lasttestar. Dette er særleg viktig når vidare komponentar er planlagde, til dømes ein REST-server eller eit Kundenportal, som genererer nye tilgangsmønster (mange små krav, paging, søkjeendepunkt).

Delphi-spesifikt: BDE-utskifting, FireDAC og reint dataåtkomstlag

I Delphi-prosjekt heng teknisk modernisering tett saman med dataåtkomst. BDE er ikkje berre «ein driver», men ein heil tilgangsstil (TTable, postbasert, navigering, lokale filter). Ein migrasjon til MariaDB er rette augneblinken for å konsolidere åtkomsten.

Frå «DataSets overalt» til kontrollert dataåtkomst

Mange applikasjonar har eigne queries i kvart skjema. Dette skalerer dårleg fagleg og sikkerheitsmessig. Ei god rettesnor er ei endring mot:

• Sentraliserte repository-/service-klassar for kjerneobjekt
• Einheitleg feilhandsaming og transaksjonshandtering
• Parametriserte queries (unngå SQL Injection, bruk plan-caching)
• Konfigurerbare connection-pools eller connection-management for tenester

Dette legg grunnlaget for ei Layer-3 arkitektur der UI, faglogikk og persistens er klart separerte. Det hjelper ikkje berre ved databaseskifte, men også ved vidare utvikling mot REST-server eller bakgrunnstenester.

MariaDB-tilkopling med FireDAC: vanlege avklaringar

I prosjekt dukkar dei same spørsmåla opp: Kva drivartype (MySQL/MariaDB), kva SSL-innstillingar, kva timezone- og datoval, kva Unicode-innstillingar? Dette er ikkje bagatellar, fordi dei påverkar datakonsistens (dato/tid), sortering og driftstryggleik (TLS). Ein kontrollert migrasjon fastset desse parametra, dokumenterer dei og testar med realistiske data.

Cutover-plan: stikkdag, datafreeze, rollback – utan overraskingar

Cutover er eit eige prosjekt. Ein god cutover-plan skildrar ikkje berre «når snuast», men òg vernetiltak:

• Datafreeze: Frå kva tidspunkt vert det ikkje lenger registrert data i gamlesystemet? Finns det beredskapsprosessar?
• Final import: Kor lang tid tek han realistisk? (Tørrkøyringar gir tal.)
• Validering: Kva sjekkar må vere grøne før godkjenning (counts, summasjonar, stikkprøver, faglege rapportar)?
• Rollback: Når avbrytast, og kva skjer då vidare?
• Kommunikasjon: Kven gir frigiving? Kven er tilgjengeleg i War Room?

Særleg i mellomstore verksemder er ein «rollback» ofte meir organisatorisk enn teknisk kritisk. Difor må migrasjonen vere så godt førebudd at cutover ikkje er eit eksperiment, men eit innstilt og øvd forløp.

Etter migrasjonen: grunnlag for REST, tenester og multiplattform

Når MariaDB går stabilt og BDE-erstatninga er gjennomført, opnar nye moglegheiter: REST-APIar for eksterne system, bakgrunnsprosessar som Windows- eller Linux-tenester, løysing av UI frå faglogikk og moglegheit for multiplattform-klientar. Vanlegvis er neste steg å løfte faglogikk ut av desktopen for å kunne handtere integrasjonar (ERP/DMS/CRM) og portalar på ein kontrollert måte.

Viktig å merke seg: Ein REST-server er ikkje ein «ekstra lag», men eit arkitekturval. Dei som allereie har konsolidert dataåtkomst, validering og rettar i tenester/repositories, kan enklare utvikle robuste APIar.

Praksis-sjekkliste: Det du bør avklare før prosjektstart

• Kva modul er forretningskritisk og må fungere sikkert på cutover-dagen?
• Korleis ser reelle datavolum ut (tabellstorleikar, vekst, arkivstrategiar)?
• Kva rapportar må vere 1:1 identiske, og kva kan betrast?
• Kva integrasjonar heng på systemet (filimport/eksport, ODBC, Office, trykkerutinar)?
• Finns det fleirkundestruktur (Mandantenfähigkeit), og i så fall: korleis er den i dag representert?
• Kva driftskrav gjeld (backup-vindauge, restore-tid, rettar, revisjon)?

Desse avklaringane er ikkje byråkrati, men hindrar at ein migrasjon blir «teknisk ferdig» utan fagleg godkjenning.

Konklusjon: Kontrollert migrasjon betyr å gjere risikoar planbare

Å migrere Paradox og BDE kontrollert til MariaDB betyr å modernisere applikasjonen som eit heilt system: datamodell, SQL, transaksjonar, teiknsett, tilgangslag og driftsprosessar. Dei som ser bytet som ein rein eksport, ender ofte opp med dei same problema dei ville kvitt seg med – berre på ein ny server.

Eit trinnvis opplegg med reproducerbar import, grundig feltskartlegging, tidleg validering og ein klar BDE-utskifting (t.d. via FireDAC) leverer derimot eit stabilt utgangspunkt: for fleirbrukardrift, for integrasjonar, for tenester og for neste steg i Delphi Modernisierung.

Om de ønskjer å planleggje migrasjonen fagleg trygt og gjennomføre utan driftsbrot, diskuterer vi gjerne utgangspunkt, risiko og ein realistisk etappeplan: https://net-base-software-gmbh.de/kontakt/