Paradox og BDE kontrollert migrere til MariaDB

Mange Delphi-fagsystemer ble bygget med Paradox-tabeller og Borland Database Engine (BDE), fordi det den gang var en pragmatisk standard: lokal, raskt klar, liten infrastruktur. I praksis kjører disse systemene ofte fortsatt i produksjon – inkludert rapportering, etikettutskrift, import/eksport, batch-jobber, historikkstabeller og spesiell logikk som over år har «sneket seg inn» i dataaksessen. Derfor er en migrasjon ikke bare et eksport av data, men en kontrollert ombygging: datamodell, SQL-atferd, bivirkninger i koden og driftsprosesser må vurderes samlet.

MariaDB er ofte et godt valg som målplattform når det gjelder robust flerbrukerdrift, konsistente transaksjoner, sentrale backups, replikasjon, klar rettighetsstyring og tilkoblingsmuligheter for webportaler, tjenester eller REST-APIs. Utfordringen er sjelden selve databaseinstallasjonen – det reelle arbeidet ligger i en sikker migrasjonsvei: Hvordan overføres tabeller, indekser, primærnøkler, tegnsett, datofelt, «tomme» verdier og referansesammenhenger korrekt uten at faglogikken bryter i produksjon?

Denne artikkelen beskriver en gjennomprøvd fremgangsmåte for å migrere Paradox og BDE kontrollert til MariaDB: teknisk forankret, trinnvis og med fokus på stabilitet. Målet er et bærekraftig grunnlag for videre modernisering – for eksempel BDE-utfasing, overgang til BDE-Ablösung mit nativer Anbindung, klar Layer-3 Architektur, REST-Server og plattformvennlige klienter.

Hvorfor Paradox/BDE-migrasjon er mer enn et databaseskifte

Paradox som filformat og BDE som tilgangslag utgjør et helhetssystem med særegenheter som man ikke bør «gjenbygge» 1:1 i MariaDB. Typiske symptomer i hverdagen er:

• Utydelige avhengigheter: SQL-sett er spredt (Forms, DataModules, Reports, dynamisk string-SQL), ofte uten sentral styring.
• Atferd «etter følelse»: Enkelte filter, sorteringer eller joins fungerer tilfeldig fordi Paradox/BDE er tolerant eller gjør implisitte typkonverteringer.
• Flerbrukerbegrensninger: Filbaserte låser, ytelsesfall i nettverk, låseproblemer ved økende datavolum.
• Vedlikeholdsrisiko: BDE-avhengigheter, gamle drivere, utfordrende deploy på moderne Windows-versjoner, 64‑bit/ARM64-temaer.

En kontrollert migrasjon tar disse punktene ikke som sideeffekt, men som målestokker. MariaDB blir da ikke bare en «ny database», men en mulighet til å frikoble dataaksesslaget, øke faglig integritet og etablere grensesnittkapasitet.

Målbilde: MariaDB som stabil databasis for desktop, tjenester og portaler

Et fornuftig målbilde for B2B-fagsystemer består som regel av tre lag:

• Database (MariaDB): konsistent datalagring, indekser, constraints, transaksjoner, brukere/roller, backup.
• Faglogikk (Server/Tjenester): valideringer, arbeidsflyt, importører, scheduler, grensesnitt. Valgfritt som REST-Server, Windows- eller Linux-tjenester.
• Klienter (VCL/FMX/Web): brukergrensesnitt, rapporter, offline-deler, integrasjoner. Ideelt med klare kontrakter mot faglogikken.

Avhengig av utgangspunktet må ikke alt implementeres umiddelbart. Men migrasjonen bør planlegges slik at den ikke stenger for en ren arkitektur i neste fase. Den som i dag bare kopierer tabeller og i morgen igjen lar hvert skjema skrive «direkte» mot databasen, har riktignok innført MariaDB, men risikobildet er uendret.

Oppsummering: Hva som faktisk må migreres

Starten er en inventar som går utover «hvor mange tabeller». I Paradox/BDE-prosjekter er det typisk at databasen bare er en del av sannheten. Viktige punkter:

1) Tabeller, indekser, «pseudo-nøkler»

Ofte mangler ekte primary keys. I stedet finnes kombinasjoner av felter, løpenumre uten entydige constraints eller «key»-felt som vedlikeholdes i applikasjonen. For MariaDB må disse bli entydige, robuste nøkler – ellers er transaksjoner og referensiell integritet bare delvis effektive.

2) Spørringer, dynamiske SQL-byggesteiner, rapporter

BDE bruker avhengig av komponent ulike SQL-dialekter og tolererer ofte «kreative» statements. Rapportkomponenter (inkludert eldre) inneholder ofte egne SQL-definisjoner. En migrasjon må finne og kategorisere disse kildene: kritiske kjerne-queries, sjelden brukte utskrifter, spesialimporter.

3) Tegnsett og spesialtegn (Umlauter, ISO/ANSI, Unicode)

Mange Paradox-applikasjoner er historisk ANSI-baserte. Hvis Delphi-applikasjonen på et tidspunkt ble satt om til Unicode, oppstår blandede tilstander: data i gammelt encoding, UI i Unicode, eksporter som forventer Windows-1252. MariaDB bør her få en klar strategi (typisk utf8mb4), inkludert ren konvertering og tester for «usynlige» feil (sammenligninger, sortering, trim/padding, spesialtegn).

4) «Tomme» verdier, null-logikk og datofelt

Paradox/BDE kjenner flere særtilfeller: tomme strenger i stedet for NULL, 0-datoer, «tomme» tidsstempler, standardverdier som oppstår i UI. MariaDB skiller strengt mellom NULL og tomt. Det påvirker WHERE-klausuler, aggregater og beregninger. Disse forskjellene må vurderes per tabell/felt.

5) Bivirkler: session-tabeller, lokal konfig, cache

Ofte finnes lokale tabeller i Paradox-strukturen for mellomresultater, eksportbuffere, brukeroppsett eller parametre. Noe bør fortsatt ligge lokalt (f.eks. UI-oppsett), annet bør sentraliseres (f.eks. arbeidsoppgaver, status, logger). En migrasjon er en anledning til å skille disse kategoriene tydelig.

Fallgruver ved Paradox/BDE: typiske tekniske forskjeller

For at migrasjon skal bli planbar, lønner det seg å eksplicit håndtere de gjentakende forskjellene.

SQL-dialekt og operatorer

BDE/Paradox-SQL er ikke identisk med MySQL/MariaDB-SQL. Forskjeller opptrer blant annet ved datofunksjoner, strengfunksjoner, outer joins (historisk), like/maskelogikk og ved implisitte typkonverteringer. En kontrollert tilnærming erstatter «det fungerer jo» med klare regler: Hvilke statements porteres, hvilke skrives bevisst om, hvilke kapsles i views/stored procedures (hvis hensiktsmessig)?

Sortering og collasjon

I Paradox er sorteringsrekkefølge og store/små bokstaver ofte annerledes enn i MariaDB, særlig for Umlauter. I MariaDB avgjør collation (f.eks. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) sammenligning og sortering. Dette er ikke akademisk: det påvirker deduplisering, søkefunksjoner og oppførselen til unique-constraints.

Autoincrement og nummerserier

Paradox har autoincrement-felt, men applikasjoner bruker ofte egne nummerserier (dokumentnummer, ordrenummer) med særskilt logikk. I MariaDB bør man skille klart:

• Teknisk primærnøkkel: AUTO_INCREMENT (eller UUID, avhengig av arkitektur) for relasjoner.
• Faglig nummer: egen nummerserie med transaksjonsbeskyttelse, eventuelt per kunde/periode.

Den som misbruker et faglig nummer som teknisk nøkkel, går ofte inn i dyre ombygginger senere.

Låsing og transaksjoner

Overgangen fra filbasert tilgang til en ekte server er en fordel, men endrer atferd. I MariaDB er transaksjoner (InnoDB) sentrale. Man må bestemme hvor transaksjonsgrensene ligger: per dialog, per lagringsoperasjon, per batch. Særlig viktig: lange transaksjoner og «edit-modus» over minutter er vanlig i Paradox-verdenen, men kritisk på serversiden (låser, deadlocks, replikasjonslag). Her er ofte en justering av arbeidsmåten eller UI-et en del av migrasjonen.

Fremgangsmodell: kontrollert migrasjon i etapper i stedet for Big Bang

I B2B-miljøer er driftstabilitet ofte viktigere enn et raskt snitt. En trinnvis migrasjonsbane reduserer risiko fordi fagavdeling og IT kan validere iterativt.

Etappe 1: Datamodelloverføring med mapping, uten kodeendring

I første steg bygges et MariaDB-skjema som speiler Paradox-strukturen – men allerede med målprinsipper: primary keys, indekser, hensiktsmessige datatyper, utf8mb4, InnoDB. Parallelt lages en repeterbar importprosess (skript/verktøy) som kan kjøres på nytt ved behov. Viktig her er repetérbarhet, fordi migrasjon aldri er «ferdig» ved første kjør.

Leveranser i denne etappen er typisk:

• Versjonert schema-definisjon (DDL) (f.eks. i Git)
• Feltmapping-liste (Paradox → MariaDB) inkl. konverteringsregler
• Import-prosedyre med logging (antall rader, feil, avvik)
• Første valideringsrapporter (counts, summer, checksums)

Etappe 2: BDE-utfasing i dataaksessen (f.eks. med FireDAC)

Det egentlige moderniseringstiltaket er å frikoble seg fra BDE. I Delphi-prosjekter er BDE-Ablosung mit nativer Anbindung en anerkjent vei fordi det gir moderne drivere, transaksjoner, parameterbinding og enhetlige komponenter for ulike SQL-backends. Det vesentlige er ikke «BDE ut», men hvordan koden ser ut etterpå: sentralisert dataaksess, entydig feilhåndtering, rene parametre i stedet for string-konkatenasjon.

Typiske oppgaver i denne etappen:

• Erstatte TTable/TQuery med FireDAC-queries og DataSets
• Innføre et data-access-lag (DAL) som basis for senere Layer-3 arkitektur
• Standardisere transaksjonsscopes (Commit/Rollback)
• SQL-gjennomgang: dialektjustering, parametre, paging, joins

Hvis applikasjonen skal moderniseres langsiktig, er dette steget ofte viktigere enn selve datamigrasjonen. Det gir teknisk frihet for 64‑bit, moderne Windows-versjoner og ryddige deploy-pipelines.

Etappe 3: Parallelldrift og faglig godkjenning uten driftsbrudd

For kritiske systemer er parallelldrift fornuftig: MariaDB settes opp og fylles periodisk (eller inkrementelt) mens eldre system fortsetter. Dette lar fagavdelingen sammenligne rapporter, identifisere randtilfeller og teste den nye plattformen under last. Parallelldrift kan realiseres på flere måter:

• Read-only-replika for rapportering/BI-forberedelse
• «Dual Write» i definerte områder (kun hvis godt kontrollert)
• Stichtagsmigrasjon med flere tørrkjøringer og en klar cutover-sjekkliste

Viktig er å ikke overkomplisere: Dual-write høres fristende ut, men er feiltolerant hvis faglogikken ikke er sentralisert. Ofte er et repeterbart stichkontrollert kjør med god validering mer økonomisk i lengden.

Etappe 4: Optimalisering, integritet, ytelse, driftsprosesser

Etter cutover begynner fasen hvor MariaDB skal utspille sine styrker: referensiell integritet, effektive indekser, klare rettigheter, overvåkning, backup/restore-tester. Her blir ofte de «reelle» produksjonsbelastningene synlige: lange rapporter, dårlig indekserte søk, batch-oppdateringer. En kontrollert migrasjon planlegger denne etappen eksplisitt i stedet for å la den bli ustrukturert etterarbeid.

Datatyper og mapping: fra Paradox til MariaDB uten informasjons-tap

Feltmapping er kjernen i migrasjonen. Typiske tilordninger (forenklet) er:

• Alpha / Memo: VARCHAR/TEXT (med utf8mb4), lengdevalidering og trim-regler
• Number: INT/BIGINT/DECIMAL avhengig av verdiområde; forsiktighet ved implisitte desimaler
• Date/Time: DATE/DATETIME/TIMESTAMP; klare regler for «0-dato» vs. NULL
• Logical: BOOLEAN eller TINYINT(1) med entydig semantikk
• Currency: DECIMAL(…,2/4) i stedet for float for å unngå avrundingsfeil

Viktig er ikke bare å oversette datatyper, men også å dokumentere fagregler: Kan et felt være NULL? Hvilke defaultverdier er faglig korrekte? Hvilke kombinasjoner må være entydige? Av dette følger constraints og indekser. Disse reglene var i Paradox/BDE-systemet ofte implisitt i UI eller kode – i MariaDB bør de, der det gir mening, bli eksplisitte.

Integritet: Primærnøkler, fremmednøkler og unike indekser

Mange legacy-databaser har fungert i årevis uten referensiell integritet – helt til integrasjoner, portaler eller parallelle prosesser kommer til. Da blir datakvalitet en begrensende faktor. I MariaDB kan man bruke Foreign Keys, Unique Constraints og CHECKs (avhengig av versjon/engine) for å fange datafeil tidlig.

En praktisk vei er å innføre integritet trinnvis:

• Først primærnøkler og unike indekser på kjerneobjekter (kunder, artikler, dokumenter)
• Deretter fremmednøkler i de stabile områdene
• For «historiske» tabeller med datarot: først rensing, så constraints

Dette reduserer risikoen for at cutover feiler på gamle data og forbedrer samtidig totaltilstanden betydelig.

Ytelse i praksis: hva endrer seg med MariaDB

Paradox/BDE-systemer er ofte optimalisert for «filhastighet»: lokale indekser, raske tabelltilganger, mye klientbasert filtrering. I MariaDB flyttes mye arbeid til serveren. Det er en fordel, men krever ryddig SQL- og indeksstrategi.

Typiske ytelsespitfall

• SELECT * fra store tabeller, fordi det tidligere var «lokalt» raskt nok
• Klientbasert filtrering i stedet for WHERE-klausuler på server
• Manglende sammensatte indekser for søkefelter (f.eks. tenant + status + dato)
• LIKE ‚%tekst%‘ uten en passende fulltekststrategi

Målbar forbedring i stedet for «etter følelse»

En kontrollert migrasjon etablerer tidlig målepunkter: Slow Query Log, Explain-analyser, reproduserbare lasttester. Dette er spesielt viktig hvis etterfølgende komponenter planlegges, for eksempel en REST-server eller et kundesenter/portal, som gir nye aksessmønstre (mange små forespørsler, paging, endepunktsøk).

Delphi-spesifikt: BDE-utfasing, FireDAC og rene tilgangslag

I Delphi-prosjekter henger teknisk modernisering tett sammen med dataaksess. BDE er ikke bare «en driver», men en hel tilgangsmodell (TTable, recordbasert, navigering, lokal filtrering). En migrasjon til MariaDB er et naturlig tidspunkt for å konsolidere aksessen.

Fra «DataSets overalt» til kontrollert dataaksess

Mange applikasjoner har egne queries i hver form. Det skalerer dårlig både faglig og sikkerhetsmessig. En velprøvd endring går i retning av:

• Sentraliserte repository-/service-klasser for kjerneobjekter
• Enhetlig feilhåndtering og transaksjonshåndtering
• Parametriserte queries (unngå SQL-injeksjon, utnytt plan-caching)
• Konfigurerbare connection-pools eller connection-management for tjenester

Dette skaper grunnlag for en Layer-3 arkitektur hvor UI, faglogikk og persistens er klart atskilt. Det hjelper ikke bare ved databaseskiftet, men også ved senere utbygging mot REST-servere eller bakgrunnstjenester.

MariaDB-tilkobling med FireDAC: typiske avklaringer

I prosjekter dukker ofte de samme spørsmålene opp: Hvilken drivervariant (MySQL/MariaDB), hvilke SSL-alternativer, hvilke timezone- og datoinnstillinger, hvilke Unicode-innstillinger? Dette er ikke bagateller, fordi de påvirker datakonsistens (tid/dato), sortering og driftssikkerhet (TLS). En kontrollert migrasjon fastsetter disse parameterne, dokumenterer dem og tester mot realistiske datasett.

Cutover-plan: stichtag, datafreeze, rollback – uten overraskelser

Cutover er et prosjekt i seg selv. En god cutover-plan beskriver ikke bare «når bytte», men også beskyttelsestiltakene:

• Datafreeze: Når stanser innskriving i altsystemet? Finnes nødprosesser?
• Endelig import: Hvor lang tid tar den realistisk? (Tørrkjør gir tall.)
• Validering: Hvilke checks må være grønne for godkjenning (counts, summer, stikkprøver, faglige rapporter)?
• Rollback: Når avbrytes, og hva er prosessen videre?
• Kommunikasjon: Hvem godkjenner? Hvem er tilgjengelig i War Room?

Spesielt i mellomstore bedrifter er «rollback» ofte ikke bare teknisk, men organisatorisk kritisk. Derfor må migrasjonen forberedes slik at cutover ikke er et eksperiment, men en øvd operasjon.

Etter migrasjonen: grunnlag for REST, tjenester og multiplattform

Når MariaDB går stabilt og BDE-utfasing er gjennomført, åpner nye muligheter: REST-APIer for eksterne systemer, bakgrunnsbehandling som Windows- eller Linux-tjenester, frikobling av UI og faglogikk og etter hvert multiplattform-klienter. Et vanlig neste steg er å flytte faglogikk ut av desktopen for å kunne betjene integrasjoner (ERP/DMS/CRM) og portaler kontrollert.

Viktig å understreke: Et REST-server er ikke «et ekstra lag», men et arkitekturvalg. Den som allerede har konsolidert dataaksess, validering og rettigheter i tjenester/repositories, får betydelig enklere arbeid ved utvikling av robuste APIer.

Praksis-sjekkliste: Hva dere bør avklare før prosjektstart

• Hvilke moduler er forretningskritiske og må fungere sikkert på cutover-dagen?
• Hvordan ser reelle datavolumer ut (tabellstørrelser, vekst, arkivkonsepter)?
• Hvilke rapporter må være 1:1 identiske, hvilke kan forbedres?
• Hvilke integrasjoner er koblet til systemet (fil-eksporter, ODBC, Office, utskriftskjeder)?
• Finnes det tenantstøtte, og i så fall: hvordan er den implementert i dag?
• Hvilke driftskrav gjelder (backupvindu, restore-tid, rettigheter, audit)?

Disse avklaringene er ikke byråkrati, men forhindrer at en migrasjon blir «teknisk ferdig» uten faglig godkjenning.

Konklusjon: Kontrollert migrering gjør risiko håndterbar

Å migrere Paradox og BDE kontrollert til MariaDB betyr å modernisere applikasjonen som et helhetssystem: datamodell, SQL, transaksjoner, tegnsett, tilgangslag og driftsprosesser. Den som ser byttet som et rent eksportarbeid, får ofte akkurat de problemene man ønsket å fjerne – nå på en ny server.

En trinnvis tilnærming med repeterbar import, gjennomarbeidet feltmapping, tidlig validering og en tydelig BDE-utfasing (f.eks. via FireDAC) skaper derimot et stabilt grunnlag: for flerbrukerdrift, for integrasjoner, for tjenester og for neste steg i Delphi Modernisierung.

Hvis dere vil planlegge migrasjonen faglig sikkert og uten driftsbrudd, diskuterer vi gjerne utgangspunkt, risikoer og en realistisk etappeplan: https://net-base-software-gmbh.de/kontakt/