Kontrolleret migrering af Paradox og BDE til MariaDB

Mange Delphi-fagsystemer er opstået med Paradox-tabeller og Borland Database Engine (BDE), fordi det dengang var en pragmatisk standard: lokalt, hurtigt klar, begrænset infrastruktur. I praksis kører disse systemer ofte fortsat i drift – inklusive rapportering, etiketudskrivning, import/eksport, batchjobs, historiktabeller og særlogik, som over år er blevet indarbejdet i dataadgangen. Derfor er en migration ikke blot et eksport af data, men en kontrolleret ombygning: datamodel, SQL-adfærd, sideeffekter i koden og driftsprocesser skal ses i sammenhæng.

MariaDB er som målplatform ofte et meget godt valg, når det handler om robust flerbrugerdrift, konsistente transaktioner, centrale backups, replikation, klar rettighedsstyring og tilslutningsmuligheder til webportaler, services eller REST-APIer. Udfordringen er sjældent selve databaseinstallationen – det reelle arbejde ligger i en sikker migrationssti: Hvordan overføres tabeller, indeks, primære nøgler, tegnsæt, datofelter, ”tomme” værdier og referentielle relationer korrekt, uden at forretningslogik bryder under drift?

Denne artikel beskriver en gennemprøvet fremgangsmåde til at migrere Paradox og BDE kontrolleret til MariaDB: teknisk funderet, trinvis og med fokus på stabilitet. Målet er et holdbart grundlag for videre moderniseringstrin – for eksempel BDE-udfasning, overgang til BDE-Ablösung mit nativer Anbindung, klar Layer-3 arkitektur, REST-servere og platformuafhængige klienter.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

Paradox som filformat og BDE som adgangslag udgør et samlet system med egenheder, som man ikke bør genskabe 1:1 i MariaDB. Typiske symptomer i hverdagen er:

• Intransparente afhængigheder: SQL-udtryk er spredt (Forms, DataModules, Reports, dynamisk string-SQL), ofte uden central governance.
• Adfærd ”på fornemmelsen”: Visse filtre, sorteringer eller joins virker tilfældigt, fordi Paradox/BDE er tolerant eller implicit typkonverterer.
• Begrænsninger ved flere brugere: Filbaserede låse, performancefald i netværket, lock-problemer ved voksende datamængder.
• Vedligeholdelsesrisici: BDE-afhængigheder, gamle drivere, vanskeligt deployment på moderne Windows-versioner, 64‑bit/ARM64-udfordringer.

En kontrolleret migration tager disse punkter som krav, ikke som bivirkninger. MariaDB bliver dermed ikke blot ”ny database”, men en mulighed for at afkoble dataadgangslaget, øge faglig integritet og skabe grænsefladekapacitet.

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

Et hensigtsmæssigt målbillede for B2B-fagsystemer består typisk af tre niveauer:

• Database (MariaDB): konsistent datalagring, indeks, constraints, transaktioner, brugere/roller, backups.
• Forretningslogik (Server/Services): valideringer, workflows, importører, scheduler, interfaces. Valgfrit som REST-server, Windows- eller Linux-services.
• Klienter (VCL/FMX/Web): brugerflader, rapporter, offline-komponenter, integrationer. Ideelt med klare kontrakter mod forretningslogikken.

Afhængigt af udgangssituationen behøver ikke alt at blive implementeret med det samme. Men migrationen bør planlægges, så den ikke spærrer vejen for en ren arkitektur. Den, der blot kopierer tabeller i dag og i morgen igen skriver ”direkte” fra hver form til databasen, har måske indført MariaDB, men de egentlige risici består.

Bestandsaufnahme: Was wirklich migriert werden muss

Først kommer en inventaropgørelse, der rækker ud over ”hvor mange tabeller”. I Paradox/BDE-projekter er det typisk, at databasen kun er en del af sandheden. Vigtige punkter:

1) Tabellen, Indizes, „Pseudo-nøgler“

Ofte mangler reelle primærnøgler. I stedet findes feltkombinationer, løbenumre uden entydig constraint eller ”key”-felter, som applikationen vedligeholder. For MariaDB skal disse blive entydige, robuste nøgler – ellers er transaktioner og referentiel integritet kun begrænset virksomme.

2) Queries, dynamiske SQL-komponenter, rapporter

BDE bruger afhængig af komponent forskellige SQL-dialekter og tolererer ”kreative” statements. Rapportkomponenter (også ældre) indeholder ofte egne SQL-definitioner. En migration skal finde og kategorisere disse kilder: kritiske kerne-queries, sjældent brugte udtræk, specialimporter.

3) Tegnsæt og specialtegn (umlaute, ISO/ANSI, Unicode)

Mange Paradox-applikationer er historisk ANSI-baserede. Hvis Delphi-applikationen selv på et tidspunkt er omlagt til Unicode, opstår blandede verdener: data i ældre encoding, UI i Unicode, eksportscripts forventer Windows-1252. MariaDB bør have en klar strategi her (typisk utf8mb4), inklusive ren konvertering og tests for ”usynlige” fejl (sammenligninger, sortering, trim/pad, specialtegn).

4) ”Tomme” værdier, NULL-logik og datofelter

Paradox/BDE har forskellige specialtilfælde: tomme strenge i stedet for NULL, 0-datoer, ”tomme” tidsstempler, defaultværdier, der opstår i UI’en. MariaDB skelner stringent mellem NULL og tomt. Det påvirker WHERE-klausuler, aggregationer og beregninger. Disse forskelle skal vurderes per tabel/felt.

5) Biprodukter: Session-tabeller, lokal konfiguration, cache

Ofte findes lokale tabeller i Paradox-strukturen til mellemdatasæt, eksportbuffere, brugerlayouts eller parametre. Noget bør fortsat være lokalt (f.eks. UI-layouts), andet bør centraliseres (f.eks. arbejdsprocesser, status, logs). En migration er en mulighed for at adskille disse kategorier klart.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

For at gøre migrationen planbar er det nyttigt eksplicit at adressere de tilbagevendende forskelle.

SQL-dialekt og operatorer

BDE/Paradox-SQL er ikke identisk med MySQL/MariaDB-SQL. Forskelle optræder bl.a. ved datofunktioner, strengfunktioner, outer joins (historisk), like-/maske-logik og implicitte typkonverteringer. En kontrolleret tilgang erstatter ”det virker jo” med klare regler: Hvilke statements porteres, hvilke skrives bevidst om, hvilke kapsles i views/stored procedures (hvis det giver mening)?

Sortering og collation

I Paradox er sorteringsrækkefølger og store/små bogstaver ofte anderledes end i MariaDB, især for æ, ø, å og andre diakritiske tegn. I MariaDB bestemmer collation (f.eks. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) sammenligning og sortering. Det er ikke akademisk: det påvirker deduplikation, søgefunktioner og adfærden af unique constraints.

Autoincrement og nummerserier

Paradox har autoincrement-felter, men applikationer bruger ofte egne nummerserier (fakturanumre, ordrenumre) med særlig logik. I MariaDB bør man klart adskille:

• Teknisk primærnøgle: AUTO_INCREMENT (eller UUID, afhængig af arkitektur) til relationer.
• Fagligt nummer: egen nummerserie med transaktionsbeskyttelse, evt. pr. kunde/periode.

Den, der misbruger et fagligt nummer som teknisk nøgle, pådrager sig senere dyre ombygninger.

Locking og transaktioner

Springet fra filbaseret adgang til en egentlig server er en gevinst, men ændrer adfærden. I MariaDB er transaktioner (InnoDB) centrale. Man må beslutte, hvor transaktionsgrænserne går: per dialog, per gemmehandling, per batch. Især vigtigt: lange transaktioner og en ”edit-mode” over mange minutter er almindeligt i Paradox-verdenen, men problematisk server-side (locks, deadlocks, replikationslag). Her er en tilpasning af arbejdsgange eller UI ofte en del af migrationen.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

I B2B-miljøer er driftstabilitet ofte vigtigere end et hurtigt snit. Et trinvis migrationsforløb reducerer risiko, fordi forretningsområder og IT iterativt kan validere.

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

I første skridt opbygges et MariaDB-schema, der afbilder Paradox-strukturen – men allerede med målprincipper: primærnøgler, indeks, fornuftige datatyper, utf8mb4, InnoDB. Parallelt udvikles en reproducerbar importproces (scripts/tools), der kan køres igen efter behov. Vigtigheden ligger i gentagelighed, fordi migration sjældent er færdig ved første kørsel.

Leverancer i denne fase er typisk:

• Versioneret schema-definition (DDL) (f.eks. i Git)
• Feltmapping-liste (Paradox → MariaDB) inkl. konverteringsregler
• Import-procedure med logging (antal rækker, fejl, outliers)
• Første valideringsrapporter (counts, summer, checksums)

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

Det egentlige moderniseringstrin er at afkoble BDE. I Delphi-projekter er BDE-Ablosung mit nativer Anbindung en velprøvet vej, fordi det tilbyder moderne drivere, transaktioner, parameterbinding og ensartede komponenter til forskellige SQL-backends. Det afgørende er ikke kun ”BDE væk”, men hvordan koden ser ud bagefter: centraliseret dataadgang, klar fejlhåndtering, rene parametre i stedet for string-konkatenation.

Typiske opgaver i denne fase:

• Erstatte TTable/TQuery med FireDAC-queries og datasets
• Indføre et data-access-lag (DAL) som fundament for senere Layer-3 arkitektur
• Standardisere transaktionsscope (commit/rollback)
• SQL-gennemgang: dialekttilpasning, parametre, paging, joins

Hvis jeres applikation skal moderniseres langsigtet, er dette trin ofte vigtigere end selve datamigreringen. Det skaber teknisk frihed til 64‑bit, moderne Windows-versioner og rene deployments.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

For kritiske systemer er parallel drift fornuftig: MariaDB opbygges og fyldes cyklisk (eller inkrementelt), mens altsystemet fortsat kører. Dermed kan forretningen sammenligne udtræk, identificere kanttilfælde og teste den nye platform under belastning. Parallel drift kan implementeres forskelligt:

• Read-only-replik til rapportering/BI-forberedelse
• ”Dual write” i afgrænsede områder (kun hvis det er velkontrolleret)
• Migrationsskifte på en fastlagt dato med flere tørkørsler og en klar cutover-checkliste

Vigtigt er ikke at gøre kompleksiteten unødigt stor: Dual-write lyder attraktivt, men er fejltruende, hvis forretningslogikken ikke er centraliseret. Ofte er en gentagelig stikdagsmigration med god validering økonomisk mere fornuftig.

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

Efter cutover begynder fasen, hvor MariaDB skal vise sine styrker: referentiel integritet, performante indeks, ren rettighedsstyring, overvågning, backup/restore-tests. Her bliver de ”reelle” produktionsbelastninger ofte synlige: lange rapporter, dårligt indekserede søgninger, batch-opdateringer. En kontrolleret migration planlægger eksplicit denne fase i stedet for at lade den opstå som uventet efterarbejde.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

Feltmapping er kernen i migrationen. Typiske tildelinger (forenklet) er:

• Alpha / Memo: VARCHAR/TEXT (med utf8mb4), længdechecks og trim-regler
• Number: INT/BIGINT/DECIMAL afhængig af værdiskala; pas på implicitte decimaler
• Date/Time: DATE/DATETIME/TIMESTAMP; klare regler for 0-dato vs. NULL
• Logical: BOOLEAN eller TINYINT(1) med entydig semantik
• Currency: DECIMAL(… ,2/4) i stedet for float for at undgå afrundingsfejl

Vigtigt er ikke kun at oversætte datatyper, men også at dokumentere faglige regler: Kan et felt være NULL? Hvilke defaultværdier er fagligt korrekte? Hvilke feltkombinationer skal være entydige? Heraf følger constraints og indeks. Disse regler var i Paradox/BDE-systemet ofte implicit i UI eller kode – i MariaDB bør de, hvor det giver mening, være eksplicitte.

Integritet: Primary Keys, Foreign Keys und eindeutige Indizes nachziehen

Mange legacy-databaser har kørt i årevis uden referentiel integritet – indtil integrationer, portaler eller parallelle processer dukker op. Snart bliver datakvalitet en begrænsende faktor. I MariaDB kan man bruge foreign keys, unique constraints og checks (afhængig af version/engine) til at fange dataproblemer tidligt.

En praktisk fremgangsmåde er at indføre integritet trinvis:

• Først primærnøgler og entydige indeks på kerneobjekter (kunder, artikler, dokumenter)
• Dernæst foreign keys i de stabile områder
• For ”historiske” tabeller med datarot: først oprydning, så constraints

Det reducerer risikoen for, at cutover fejler på grund af gammel ballast, samtidig med at den samlede situation forbedres markant.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE-systemer er ofte optimeret til ”fil-hastighed”: lokale indeks, hurtige tabeladgange, meget klient-side filtrering. Med MariaDB flyttes arbejdet til serveren. Det er fordelagtigt, men kræver rene SQL- og indeksstrategier.

Typische Performance-Fallen

• SELECT * fra store tabeller, fordi det tidligere var hurtigt lokalt
• Klientside-filtrering i stedet for server-side WHERE-klausuler
• Manglende sammensatte indeks på søgefelter (f.eks. tenant + status + dato)
• LIKE ‚%text%‘ uden passende fuldtekststrategi

Messbar verbessern statt „nach Gefühl“

En kontrolleret migration etablerer tidligt målepunkter: Slow Query Log, EXPLAIN-analyser, reproducerbare belastningstests. Det er især vigtigt, hvis migrationen følges af komponenter som en REST-server eller et kundenportal, der skaber nye adgangsmønstre (mange små forespørgsler, paging, søgeendpoints).

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

I Delphi-projekter hænger teknisk modernisering tæt sammen med dataadgang. BDE er ikke blot ”en driver”, men en hel adgangsstil (TTable, recordbaseret, navigation, lokale filtre). En migration til MariaDB er det rette tidspunkt til at konsolidere adgangen.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Mange applikationer har egne queries i hver enkelt form. Det skalerer dårligt fagligt og sikkerhedsmæssigt. En velafprøvet omstilling går i retning af:

• Centrale repository-/service-klasser for kerneobjekter
• Ensartet fejlhåndtering og transaktionsstyring
• Parametriserede queries (for at undgå SQL-injektion, udnytte plan-cache)
• Konfigurerbar connection-pooling eller connection-management for services

Dermed opstår et grundlag for en Layer-3 arkitektur, hvor UI, forretningslogik og persistens er klart adskilt. Det hjælper ikke alene ved databaseskiftet, men også ved senere udbygning mod REST-servere eller baggrundstjenester.

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

I projekter dukker de samme spørgsmål op: Hvilken drivervariant (MySQL/MariaDB), hvilke SSL-indstillinger, hvilke timezone- og datoindstillinger, hvilke Unicode-settings? Det er ikke småting, fordi de direkte påvirker datakonsistens (dato/tid), sortering og driftssikkerhed (TLS). En kontrolleret migration fastlægger disse parametre, dokumenterer dem og tester dem med realistiske data.

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

Cutover er et projekt i sig selv. En god cutover-plan beskriver ikke kun ”hvornår skiftes”, men også beskyttelsesforanstaltningerne:

• Datafreeze: Fra hvornår registreres der ikke længere data i altsystemet? Findes der nødprocedurer?
• Endelig import: Hvor lang tid tager den realistisk? (Tørkørsler giver tal.)
• Validering: Hvilke checks skal være grønne før frigivelse (counts, summer, stikprøver, faglige rapporter)?
• Rollback: Hvornår afbrydes, og hvordan fortsætter man så?
• Kommunikation: Hvem godkender? Hvem er tilgængelig i beredskabsrummet?

Især i mellemstore virksomheder er en rollback ofte ikke teknisk, men organisatorisk kritisk. Derfor skal migrationen være forberedt, så cutover ikke er et eksperiment, men en gennemprøvet procedure.

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

Når MariaDB kører stabilt, og BDE-udfasningen er udført, åbner der sig nye muligheder: REST-APIer til eksterne systemer, baggrundsbehandling som Windows- eller Linux-services, afkobling af UI og forretningslogik samt perspektivet om multiplatform-klienter. Et meget almindeligt næste skridt er at flytte forretningslogik ud af desktop-klienten for at betjene integrationer (ERP/DMS/CRM) og portaler kontrolleret.

Vigtigt: En REST-server er ikke blot ”et ekstra lag”, men et arkitekturvalg. Den, der allerede har konsolideret dataadgang, validering og rettigheder i services/repositories, kan langt lettere udvikle robuste APIer derfra.

Praxis-Checkliste: Was Sie vor Projektstart klären sollten

• Hvilke moduler er forretningskritiske og skal køre sikkert på cutover-dagen?
• Hvordan ser de reelle datavolumener ud (tabellestørrelser, vækst, arkivkoncept)?
• Hvilke rapporter skal være 1:1 identiske, hvilke må forbedres?
• Hvilke integrationer er afhængige af systemet (fil-eksporter, ODBC, Office, udskriftsflow)?
• Findes der multi-tenant funktionalitet, og i så fald: hvordan er den i dag afbildet?
• Hvilke driftskrav gælder (backupvindue, restore-tid, rettigheder, audit)?

Disse afklaringer er ikke bureaukrati, men forhindrer, at en migration bliver ”teknisk færdig” uden at blive fagligt godkendt.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

At migrere Paradox og BDE kontrolleret til MariaDB betyder at modernisere applikationen som et samlet system: datamodel, SQL, transaktioner, tegnsæt, adgangslag og driftsprocesser. Den, der betragter skiftet som et rent eksportjob, ender ofte med netop de problemer, man ønskede at slippe for – blot på en ny server.

En trinvis fremgang med reproducerbar import, klart feltmapping, tidlig validering og en tydelig BDE-udfasning (f.eks. via FireDAC) skaber derimod et stabilt fundament: for flerbrugerdrift, integrationer, services og de næste skridt i Delphi Modernisierung.

Hvis I vil planlægge jeres migration fagligt sikkert og uden driftsafbrydelse, gennemgår vi gerne udgangssituation, risici og en realistisk etapeplan: https://net-base-software-gmbh.de/kontakt/