Paradox och BDE kontrollerat migreras till MariaDB

Många Delphi-branschspecifika applikationer har vuxit fram med Paradox-tabeller och Borland Database Engine (BDE), eftersom det då var en pragmatisk standard: lokalt, snabbt att komma igång, och med liten infrastruktur. I praktiken körs dessa system ofta fortfarande i produktion – inklusive rapportering, etikettutskrift, import/export, batchjobb, historiktabeller och speciallogik som under år har ”arbetat sig in” i dataåtkomsten. Just därför är en migration inte bara en export av data, utan en kontrollerad ombyggnad: datamodell, SQL-beteende, sidoeffekter i koden och driftsprocesser måste betraktas tillsammans.

MariaDB är ofta ett mycket bra val som målplattform när det handlar om robust fleranvändardrift, konsistenta transaktioner, centrala backup-rutiner, replikation, tydlig behörighetsstyrning och anslutningsmöjligheter för webbportaler, tjänster eller REST-API:er. Utmaningen är sällan själva databasinstallationen – den verkliga arbetsinsatsen ligger i den säkra migrationsvägen: Hur överförs tabeller, index, primärnycklar, teckenuppsättningar, datumfält, ”tomma” värden och referentiella relationer korrekt utan att affärslogiken i drift bryts?

Detta inlägg beskriver ett beprövat förhållningssätt för att kontrollerat migrera Paradox och BDE till MariaDB: tekniskt förankrat, stegvis och med fokus på stabilitet. Målet är en hållbar grund för vidare moderniseringssteg – till exempel BDE-ersättning, byte till BDE-ersättning med nativen anslutning, tydlig Layer-3 arkitektur, REST-servrar och plattformsanpassade klienter.

Varför Paradox/BDE-migration är mer än ett databasbyte

Paradox som filformat och BDE som åtkomstlager bildar ett helhetssystem med särdrag som man inte bör återskapa 1:1 i MariaDB. Typiska symptom i vardagen är:

• Ogenomskinliga beroenden: SQL-satser är utspridda (Forms, DataModules, Reports, dynamisk string-SQL), ofta utan central styrning.
• ”Känslobaserat” beteende: Vissa filter, sorteringar eller joins fungerar av en slump eftersom Paradox/BDE är tolerant eller implicit typkonverterar.
• Begränsningar i fleranvändarscenario: Filbaserade lås, prestandaförsämringar i nätverk, låsproblem vid växande datavolymer.
• Underhållsrisker: BDE-beroenden, gamla drivrutiner, svårt deployment på moderna Windows-versioner, 64‑Bit/ARM64-frågor.

En kontrollerad migration tar dessa punkter inte som en bieffekt, utan som målkrav. MariaDB blir då inte bara ”ny databas”, utan en möjlighet att avkoppla dataåtkomstlagret, höja affärsintegriteten och skapa integrationsmöjligheter.

Målbild: MariaDB som stabil databas för desktop, tjänster och portaler

En rimlig målbild för B2B-fackapplikationer består ofta av tre nivåer:

• Databas (MariaDB): konsekvent datahantering, index, constraints, transaktioner, användare/roller, backup.
• Affärslogik (Server/Tjänster): valideringar, workflows, importörer, schemaläggare, gränssnitt. Valfritt som REST-server, Windows- eller Linux-tjänster.
• Klienter (VCL/FMX/Web): användargränssnitt, rapporter, offline-komponenter, integrationer. Helst med tydliga kontrakt mot affärslogiken.

Beroende på utgångsläget behöver inte allt genomföras omedelbart. Men migrationen bör planeras så att vägen till en ren arkitektur inte spärras. Den som idag bara kopierar tabeller och redan imorgon låter varje formulär skriva ”direkt” mot databasen har visserligen infört MariaDB, men kvarstår med de egentliga riskerna.

Inventering: Vad som verkligen måste migreras

I början står en inventering som går bortom frågan ”hur många tabeller”. I Paradox/BDE-projekt är det typiskt att databasen bara är en del av sanningen. Viktiga punkter:

1) Tabeller, index, ”pseudo-nycklar”

Ofta saknas riktiga primära nycklar. Istället finns kombinationer av fält, löpnummer utan tydliga constraints eller ”nyckelfält” som sköts i applikationen. För MariaDB måste dessa bli entydiga, robusta nycklar – annars är transaktioner och referentiell integritet bara delvis effektiva.

2) Queries, dynamiska SQL-bitar, rapporter

BDE använder beroende på komponent olika SQL-dialekter och tolererar ”kreativa” satser. Rapportkomponenter (även äldre) innehåller ofta egna SQL-definitioner. En migration måste hitta och kategorisera dessa källor: kritiska kärnqueries, sällan använda analyser, specialimporter.

3) Teckenuppsättning och specialtecken (umlaute, ISO/ANSI, Unicode)

Många Paradox-applikationer är historiskt ANSI-baserade. Om Delphi-applikationen själv någon gång har gått över till Unicode uppstår blandningar: data i gammalt encoding, UI i Unicode, exporter som förväntar sig Windows-1252. MariaDB bör här få ett tydligt koncept (typiskt utf8mb4), inklusive noggrann konvertering och tester för ”osynliga” fel (jämförelser, sortering, Trim/Pad, specialtecken).

4) ”Tomma” värden, NULL-logik och datumfält

Paradox/BDE har flera specialfall: tomma strängar istället för NULL, 0-datum, ”tomma” tidsstämplar, defaultvärden som uppstår i UI. MariaDB skiljer strikt mellan NULL och tomt. Det påverkar WHERE-klausuler, aggregeringar och beräkningar. Dessa skillnader måste utvärderas per tabell/fält.

5) Bisyften: sessions-tabeller, lokal konfiguration, cache

Ofta finns i Paradox-strukturen lokala tabeller för mellankalkyler, exportbuffertar, användarlayouter eller parametrar. Vissa saker bör fortsatt vara lokala (t.ex. UI-layouter), andra bör centraliseras (t.ex. arbetsflöden, status, loggar). En migration är en möjlighet att tydligt separera dessa kategorier.

Fallgropar vid Paradox/BDE: typiska tekniska skillnader

För att göra migrationen planbar är det värt att explicit adressera återkommande skillnader.

SQL-dialekt och operatorer

BDE/Paradox-SQL är inte identisk med MySQL/MariaDB-SQL. Skillnader visar sig bland annat i datumfunktioner, strängfunktioner, outer joins (historiskt), Like/masklogik och i implicita typkonverteringar. En kontrollerad strategi ersätter ”fungerar redan” med tydliga regler: Vilka satser porteras, vilka skrivs om medvetet, vilka kapslas i vyer/stored procedures (om det är lämpligt)?

Sortering och collation

I Paradox är sorteringsordningar och skiftlägeskänslighet ofta annorlunda än i MariaDB, särskilt för umlaute. I MariaDB avgör collation (t.ex. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) jämförelse och sortering. Det är ingen akademisk detalj: det påverkar deduplicering, sökfunktioner och beteendet hos unique-constraints.

Autoincrement och nummerserier

Paradox har autoincrement-fält, men applikationer använder ofta egna nummerserier (verifikationsnummer, ordernummer) med speciallogik. I MariaDB bör man tydligt separera:

• Teknisk primärnyckel: AUTO_INCREMENT (eller UUID, beroende på arkitektur) för relationer.
• Affärsnummer: separat nummerserie med transaktionsskydd, eventuellt per klient/period.

Den som försöker missbruka ett affärsnummer som teknisk nyckel får senare dyra ombyggnader.

Låsning och transaktioner

Steget från filbaserad åtkomst till en riktig server är en förbättring, men det förändrar beteendet. I MariaDB är transaktioner (InnoDB) centrala. Man måste besluta var transaktionsgränserna går: per dialog, per sparoperation eller per batch. Särskilt viktigt: långa transaktioner och ett ”redigeringsläge” över minuter är vanligt i Paradox-världen, men server-side kritiskt (lås, deadlocks, replikationslagg). Här är ofta en anpassning av arbetsmetodik eller UI del av migrationen.

Arbetsmodell: kontrollerad migration i etapper istället för Big Bang

I B2B-miljöer är driftstabilitet ofta viktigare än ett snabbt snitt. En etappvis migrationsväg minskar risk eftersom verksamhet och IT iterativt kan validera.

Etapp 1: Datamodellsöverföring med mapping, utan kodändring

I första steget byggs ett MariaDB-schema som avbildar Paradox-strukturen – men redan med målsättningar: primärnycklar, index, lämpliga datatyper, utf8mb4, InnoDB. Parallellt skapas en reproducerbar importprocess (skript/verktyg) som kan upprepas vid behov. Viktigt här är upprepbarheten, eftersom migration aldrig blir ”klar” vid första körningen.

Leverabler i denna etapp är typiskt:

• Schema-definition (DDL) versionshanterad (t.ex. i Git)
• Fältmappningslista (Paradox → MariaDB) inkl. konverteringsregler
• Importprocedur med loggning (antal poster, fel, avvikare)
• Första valideringsrapporter (counts, summor, checksummor)

Etapp 2: BDE-ersättning i dataåtkomst (t.ex. med FireDAC)

Det egentliga moderniseringssteget är att avkoppla sig från BDE. I Delphi-projekt är BDE-Ablosung mit nativer Anbindung en beprövad väg eftersom det erbjuder moderna drivrutiner, transaktioner, parameterbindning och enhetliga komponenter för olika SQL-backends. Avgörande är inte att ”BDE ut”, utan hur koden ser ut därefter: central dataåtkomst, tydlig felhantering, rena parametrar istället för strängkonkatenering.

Typiska uppgifter i denna etapp:

• Byta ut TTable/TQuery mot FireDAC-queries och DataSets
• Införa ett Data-Access-lager (DAL) som grund för senare Layer-3-arkitektur
• Standardisera transaktionsscopes (Commit/Rollback)
• SQL-granskning: dialektanpassning, parametrar, paging, joins

Om er applikation långsiktigt ska moderniseras är detta steg ofta viktigare än ren datamigration. Det skapar teknisk frihet för 64‑Bit, moderna Windows-versioner och rena deployments.

Etapp 3: Parallellkörning och funktionell godkännande utan driftavbrott

För kritiska system är parallellkörning lämpligt: MariaDB byggs upp och fylls cykliskt (eller inkrementellt) medan det gamla systemet fortsätter. Därigenom kan verksamheten jämföra rapporter, identifiera kantfall och testa plattformen under last. Parallellkörning kan genomföras på olika sätt:

• Read-only-replica för rapportering/BI-förberedelse
• ”Dual Write” i definierade delområden (endast om det är väl kontrollerat)
• Stichtagsmigration med flera torrkörningar och tydlig cutover-checklista

Viktigt är att inte öka komplexiteten i onödan: Dual-Write låter attraktivt men är felbenäget om affärslogiken inte är centraliserad. Ofta är en upprepad stichtagskörning med god validering i slutändan mer kostnadseffektiv.

Etapp 4: Optimering, integritet, prestanda, driftsprocesser

Efter cutover påbörjas fasen där MariaDB ska utnyttja sina styrkor: referentiell integritet, effektiva index, tydliga behörigheter, övervakning, backup/restore-tester. Här blir ofta de ”verkliga” produktionslaster synliga: långa rapporter, dåligt indexerade sökmasker, batchuppdateringar. En kontrollerad migration planerar denna etapp explicit istället för att låta den uppstå som oplanerat efterarbete.

Datatyper och mapping: från Paradox till MariaDB utan informationsförlust

Fältmappningen är kärnan i migrationen. Typiska tilldelningar (förenklat) är:

• Alpha / Memo: VARCHAR/TEXT (med utf8mb4), längdkontroller och trim-regler
• Number: INT/BIGINT/DECIMAL beroende på värdeomfång; försiktighet vid implicita decimaler
• Date/Time: DATE/DATETIME/TIMESTAMP; tydliga regler för ”0-datum” respektive NULL
• Logical: BOOLEAN eller TINYINT(1) med entydig semantik
• Currency: DECIMAL(…,2/4) istället för float för att undvika avrundningsfel

Viktigt är inte bara att översätta datatyper utan också att dokumentera affärsregler: Får ett fält vara NULL? Vilka defaultvärden är affärsmässigt korrekta? Vilka kombinationer måste vara unika? Därav följer constraints och index. Dessa regler var i Paradox/BDE-system ofta implicita i UI eller kod – i MariaDB bör de där det är meningsfullt bli explicita.

Integritet: primärnycklar, foreign keys och unika index

Många legacy-databaser har fungerat i åratal utan referentiell integritet – tills integrationer, portaler eller parallella processer tillkommer. Då blir datakvaliteten snabbt begränsande. I MariaDB kan Foreign Keys, Unique Constraints och Checks (beroende på version/engine) användas för att fånga datainkonsistenser tidigt.

En praktisk väg är att införa integritet stegvis:

• Först primärnycklar och unika index på kärnobjekt (kunder, artiklar, dokument)
• Sedan foreign keys i de stabila områdena
• För ”historiska” tabeller med smutsiga data: först rensning, sedan constraints

Det minskar risken att cutovern misslyckas på grund av gamla fel och förbättrar samtidigt helhetsläget avsevärt.

Prestanda i praktiken: vad som förändras med MariaDB

Paradox/BDE-system är ofta optimerade för ”filhastighet”: lokala index, snabba tabellåtkomster, mycket klientbaserad filtrering. Med MariaDB flyttas jobbet till servern. Det är fördelaktigt men kräver rena SQL- och indexstrategier.

Typiska prestandafällor

• SELECT * från stora tabeller eftersom det tidigare var tillräckligt snabbt lokalt
• Klientbaserad filtrering istället för serverbaserade WHERE-klausuler
• Saknade sammansatta index för sökmaskefält (t.ex. klient + status + datum)
• LIKE ‚%text%‘ utan lämplig fulltextstrategi

Mätbar förbättring istället för ”på känn”

En kontrollerad migration etablerar tidigt mätpunkter: Slow Query Log, Explain-analyser, reproducerbara lasttester. Det är särskilt viktigt när efter migrationen ytterligare komponenter planeras, t.ex. en REST-server eller ett kundportal som genererar nya åtkomstmönster (många små anrop, paging, sökändpunkter).

Delphi-specifikt: BDE-ersättning, FireDAC och rena åtkomstlager

I Delphi-projekt är teknisk modernisering tätt kopplad till dataåtkomst. BDE är inte bara ”en drivrutin”, utan en hel åtkomststil (TTable, record-baserat, navigering, lokal filtrering). En migration till MariaDB är rätt tillfälle att konsolidera åtkomsten.

Från ”DataSets överallt” till kontrollerad dataåtkomst

Många applikationer har egna queries i varje form. Det skalar dåligt både funktionellt och säkerhetsmässigt. Ett beprövat angreppssätt är en övergång mot:

• Centrala repository-/serviceklasser för kärnobjekt
• Enhetlig fel- och transaktionshantering
• Parametriserade queries (för att undvika SQL-injektion, och för att nyttja plan-caching)
• Konfigurerbara connection-pools eller connection-management för tjänster

Det skapar en grund för en Layer-3 arkitektur där UI, affärslogik och persistens är tydligt separerade. Det underlättar inte bara databasbytet utan också senare utbyggnad mot REST-servrar eller bakgrundstjänster.

MariaDB-anslutning med FireDAC: vad som vanligtvis måste klargöras

I projekt återkommer alltid samma frågor: vilken drivrutinstyp (MySQL/MariaDB), vilka SSL-alternativ, vilka timezone- och datuminställningar, vilka Unicode-inställningar? Det är inga oväsentligheter eftersom de direkt påverkar datakonsistens (datum/tid), sortering och driftsäkerhet (TLS). En kontrollerad migration fastställer dessa parametrar, dokumenterar dem och testar dem med realistiska data.

Cutover-plan: stichtag, datafreeze, rollback – utan överraskningar

Cutovern är ett projekt i sig. En bra cutover-plan beskriver inte bara ”när man växlar”, utan också skyddsåtgärder:

• Datafreeze: Från när registreras inga fler data i legacy-systemet? Finns undantagsrutiner?
• Slutgiltig import: Hur lång tid tar den realistiskt? (torrkörningar ger siffror)
• Validering: Vilka kontroller måste vara gröna före frigivning (counts, summor, stickprov, affärsrapporter)?
• Rollback: När avbryter man, och hur går man vidare då?
• Kommunikation: Vem ger godkännande? Vem sitter i war room?

Särskilt i medelstora företag är en ”rollback” ofta organisatoriskt snarare än tekniskt kritisk. Därför måste migrationen förberedas så att cutovern inte är ett experiment utan en övad procedur.

Efter migrationen: grund för REST, tjänster och multiplattform

När MariaDB går stabilt och BDE-ersättningen är genomförd uppstår nya möjligheter: REST-API:er för externa system, bakgrundsbehandling som Windows- eller Linux-tjänster, avkoppling av UI och affärslogik samt i förlängningen multiplattforms-klienter. Ett vanligt nästa steg är att flytta affärslogik ut från desktopen för att hantera integrationer (ERP/DMS/CRM) och portaler kontrollerat.

Viktigt att notera: en REST-server är ingen ”ytterligare lager” utan ett arkitekturbeslut. Den som redan konsoliderat dataåtkomst, validering och behörigheter i tjänster/repositories kan betydligt enklare bygga robusta API:er av detta.

Praktisk checklista: Vad ni bör klargöra före projektstart

• Vilka moduler är affärskritiska och måste fungera säkert på cutover-dagen?
• Hur ser verkliga datavolymer ut (tabellstorlekar, tillväxt, arkivkoncept)?
• Vilka rapporter måste vara 1:1 identiska, vilka får förbättras?
• Vilka integrationer är beroende av systemet (filexports, ODBC, Office, utskriftsflöden)?
• Finns multi-tenant-stöd, och i så fall: hur är det idag implementerat?
• Vilka driftkrav gäller (backup-fönster, restore-tid, behörigheter, revision)?

Dessa klargöranden är inte byråkrati utan förhindrar att en migration blir ”tekniskt klar” men funktionellt icke godkänd.

Slutsats: Kontrollerad migration gör riskerna planbara

Att kontrollerat migrera Paradox och BDE till MariaDB innebär att modernisera applikationen som ett helhetssystem: datamodell, SQL, transaktioner, teckenuppsättningar, åtkomstlager och driftsprocesser. Den som ser bytet som en ren export får oftast precis de problem man ville bli av med – bara på en ny server.

Ett stegvis tillvägagångssätt med reproducerbar import, noggrant fältmapping, tidig validering och en tydlig BDE-ersättning (t.ex. via FireDAC) skapar däremot en stabil grund: för fleranvändardrift, för integrationer, för tjänster och för nästa steg i Delphi Modernisierung.

Om ni vill planera er migration fackmässigt och genomföra den utan driftavbrott diskuterar vi gärna utgångsläge, risker och en realistisk etappplan: https://net-base-software-gmbh.de/kontakt/