Paradox en BDE gecontroleerd naar MariaDB migreren

Veel Delphi-vaktoepassingen zijn ontstaan met Paradox-tabellen en de Borland Database Engine (BDE), omdat dat destijds een pragmatische standaard was: lokaal, snel inzetbaar, weinig infrastructuur. In de praktijk draaien deze systemen vaak nog steeds productief – inclusief reporting, etikettenprint, import/export, batch-jobs, historietabellen en specialelogica die zich over jaren in de dataaccess „ingewerkt“ heeft. Juist daarom is een migratie niet slechts een export van gegevens, maar een gecontroleerde herbouw: datamodel, SQL-gedrag, neveneffecten in code en operationele processen moeten samen worden bekeken.

MariaDB is als doelplatform vaak een zeer goede keuze wanneer het gaat om robuuste meergebruikerswerking, nette transacties, centrale backups, replicatie, een heldere rechtenstructuur en de aansluitbaarheid voor webportals, services of REST-API’s. De uitdaging is zelden de database-installatie zelf – de werkelijke inspanning zit in het veilige migratiepad: hoe worden tabellen, indexen, primary keys, tekencoderingen, datumvelden, „lege“ waarden en referentiële relaties correct overgezet, zonder dat de vaklogica in de productieomgeving breekt?

Dit artikel beschrijft een beproefde werkwijze om Paradox en BDE gecontroleerd naar MariaDB te migreren: technisch gefundeerd, stapsgewijs en met focus op stabiliteit. Doel is een draagbare basis voor verdere moderniseringsstappen – bijvoorbeeld BDE-vervanging, overstap naar BDE-Ablösung mit nativer Anbindung, duidelijke Layer-3 Architektur, REST-Server en platformgeschikte clients.

Waarom Paradox/BDE-migratie meer is dan een databasewissel

Paradox als bestandsformaat en de BDE als toegangslayer vormen een totaal systeem met eigenaardigheden die je in MariaDB niet 1:1 zou moeten „nabouwen“. Typische symptomen in de dagelijkse praktijk zijn:

• Ondoorzichtige afhankelijkheden: SQL-statements zijn verspreid (Forms, DataModules, Reports, dynamische string-SQL), vaak zonder centrale governance.
• Gedrag „op gevoel“: Bepaalde filters, sorteringen of joins werken toevallig omdat Paradox/BDE tolerant is of impliciet typeconverteert.
• Meergebruikersbegrenzingen: Bestandsgebaseerde locks, prestatie-invallen in het netwerk, locking-problemen bij groeiend datavolume.
• Onderhoudsrisico’s: BDE-afhankelijkheden, oude drivers, lastige deployment op moderne Windows-versies, 64‑bit/ARM64-issues.

Een gecontroleerde migratie neemt deze punten niet als neveneffect, maar als doelcriteria. MariaDB wordt dan niet alleen de „nieuwe database“, maar de kans om de dataaccesslaag te ontkoppelen, de vakmatige integriteit te verhogen en interface-geschiktheid te realiseren.

Doelbeeld: MariaDB als stabiele databasis voor desktop, services en portals

Een zinvol doelbeeld voor B2B-vakapplicaties bestaat meestal uit drie lagen:

• Database (MariaDB): consistente dataopslag, indexen, constraints, transacties, gebruikers/rollen, backups.
• Vaklogica (Server/Services): validaties, workflows, importers, scheduler, interfaces. Optioneel als REST-Server, Windows- of Linux-Services.
• Clients (VCL/FMX/Web): gebruikersinterfaces, rapporten, offline-delen, integraties. Idealiter met heldere contracten richting de vaklogica.

Afhankelijk van de uitgangssituatie hoeft niet alles onmiddellijk te worden gerealiseerd. Maar de migratie moet zo gepland zijn dat ze het pad naar een nette architectuur niet verspert. Wie vandaag alleen tabellen kopieert en morgen weer „rechtstreeks“ vanuit elk formulier naar de database laat schrijven, heeft weliswaar MariaDB ingevoerd, maar de feitelijke risico’s blijven bestaan.

Voorraadopname: wat er daadwerkelijk gemigreerd moet worden

Aan het begin staat een inventarisatie die verder gaat dan „hoeveel tabellen“. In Paradox/BDE-projecten is het typisch dat de database slechts een deel van de waarheid is. Belangrijke punten:

1) Tabellen, indexen, „pseudo-sleutels“

Vaak ontbreken echte primary keys. In plaats daarvan bestaan combinaties van velden, volgnummeringen zonder expliciete constraint of „key“-velden die in de applicatie worden beheerd. Voor MariaDB moeten daaruit unieke, betrouwbare sleutels worden gemaakt – anders zijn transacties en referentiële integriteit slechts beperkt effectief.

2) Queries, dynamische SQL-blokken, rapporten

BDE gebruikt per component verschillende SQL-dialecten en tolereert „creatieve“ statements. Reporting-componenten (ook oudere) bevatten vaak eigen SQL-definities. Een migratie moet deze bronnen vinden en categoriseren: kritische kern-queries, zelden gebruikte overzichten, speciale importen.

3) Tekenset en speciale tekens (umlauten, ISO/ANSI, Unicode)

Veel Paradox-applicaties zijn historisch ANSI-gebaseerd. Als de Delphi-applicatie zelf ooit op Unicode is gesteld, ontstaan mengvormen: data in oud encoding, UI is Unicode, exports verwachten Windows-1252. MariaDB moet hier een helder concept krijgen (typisch utf8mb4), inclusief nette conversie en tests op „onzichtbare“ fouten (vergelijkingen, sortering, trim/pad, speciale tekens).

4) „Lege“ waarden, null-logica en datumvelden

Paradox/BDE kent diverse specialcases: lege strings in plaats van NULL, 0-datums, „lege“ timestamps, defaultwaarden die in de UI ontstaan. MariaDB maakt strikt onderscheid tussen NULL en leeg. Dat beïnvloedt WHERE-clauses, aggregaties en berekeningen. Deze verschillen moeten per tabel/veld worden beoordeeld.

5) Nevenartefacten: sessietabellen, lokale configuratie, cache

Vaak bevinden zich in de Paradox-structuur lokale tabellen voor tussenresultaten, exportbuffers, gebruikerslayouts of parameters. Sommige zaken horen lokaal te blijven (bijv. UI-layouts), andere horen centraal (bijv. werkprocessen, statussen, logs). Een migratie is een kans om deze categorieën helder te scheiden.

Valkuilen bij Paradox/BDE: typische technische verschillen

Om migratie planbaar te maken is het zinvol om de terugkerende verschillen expliciet aan te pakken.

SQL-dialect en operatoren

BDE/Paradox-SQL is niet identiek aan MySQL/MariaDB-SQL. Verschillen treden op bij datumfuncties, stringfuncties, outer joins (historisch), like/maskerlogica en impliciete typeconversies. Een gecontroleerde aanpak vervangt „werkt wel“ door duidelijke regels: welke statements worden geporteerd, welke worden bewust herschreven, welke worden ingekapseld in views/stored procedures (indien zinvol)?

Sortering en collation

In Paradox zijn sorteerordes en hoofdlettergevoeligheid vaak anders dan in MariaDB, met name bij umlauten. In MariaDB bepaalt de collation (bijv. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) vergelijkingen en sortering. Dit is geen academische kwestie: het beïnvloedt deduplicatie, zoekfuncties en het gedrag van unique constraints.

Autoincrement en nummerkringen

Paradox kent autoincrementvelden, maar applicaties gebruiken vaak eigen nummerkringen (documentnummers, ordernummers) met speciale logica. In MariaDB moet dit duidelijk worden gescheiden:

• Technische primary key: AUTO_INCREMENT (of UUID, afhankelijk van de architectuur) voor relaties.
• Vakmatig nummer: eigen nummerkring met transactionele bescherming, eventueel per klant/boekperiode.

Wie probeert een vakmatig nummer als technische sleutel te misbruiken, veroorzaakt later dure herbouw.

Locking en transacties

De stap van bestandsgebaseerde toegang naar een echte server is winst, maar verandert het gedrag. In MariaDB zijn transacties (InnoDB) centraal. Men moet beslissen waar transactieranden liggen: per dialoog, per opslaanhandeling, per batch. Vooral belangrijk: lange transacties en een „edit-modus“ van meerdere minuten zijn in Paradox-werelden gebruikelijk, maar serverzijdig problematisch (locks, deadlocks, replicatie-lag). Hier hoort vaak een aanpassing van werkwijze of UI bij de migratie.

Vorgehensmodell: gecontroleerde migratie in fasen in plaats van Big Bang

In B2B-omgevingen is operationele stabiliteit vaak belangrijker dan een snelle knip. Een gefaseerd migratiepad vermindert risico omdat business en IT iteratief kunnen valideren.

Fase 1: datamodel-transfer met mapping, zonder codeherbouw

In de eerste stap wordt een MariaDB-schema opgezet dat de Paradox-structuur afbeeldt – maar al met doelprincipes: primary keys, indexen, zinvolle datatypes, utf8mb4, InnoDB. Parallel wordt een reproduceerbaar importproces gemaakt (scripts/tools) dat zo nodig herhaald kan worden. Belangrijk is herhaalbaarheid, omdat migratie zelden bij de eerste run „klaar“ is.

Deliverables van deze fase zijn typisch:

• Schema-definitie (DDL) versioneerd (bijv. in Git)
• Veldmapping-lijst (Paradox → MariaDB) incl. conversieregels
• Import-procedure met logging (aantal records, fouten, outliers)
• eerste validatiereports (counts, sommen, checksums)

Fase 2: BDE-vervanging in de dataaccess (bijv. met FireDAC)

De daadwerkelijke moderniseringsstap is het ontkoppelen van de BDE. In Delphi-projecten is BDE-Ablosung mit nativer Anbindung een bewezen weg omdat het moderne drivers, transacties, parameterbinding en uniforme componenten voor verschillende SQL-backends biedt. Beslissend is niet „BDE eruit“, maar hoe de code er daarna uitziet: centrale dataaccess, eenduidige foutafhandeling, nette parameters in plaats van stringconcatenatie.

Typische taken in deze fase:

• Vervangen van TTable/TQuery door FireDAC-queries en DataSets
• Invoeren van een data-access-laag (DAL) als basis voor latere Layer-3-architectuur
• Standaardiseren van transaction-scopes (Commit/Rollback)
• SQL-review: dialectaanpassing, parameters, paging, joins

Als uw applicatie op langere termijn gemoderniseerd moet worden, is deze stap vaak belangrijker dan de zuivere datamigratie. Ze creëert de technische vrijheid voor 64‑bit, moderne Windows-versies en nette deployment-pipelines.

Fase 3: parallelbedrijf en vakinhoudelijke acceptatie zonder productieonderbreking

Voor kritische systemen is parallelbedrijf zinvol: MariaDB wordt opgezet en cyclisch (of incrementeel) gevuld, terwijl het oude systeem doorloopt. Daardoor kan de business overzichten vergelijken, randgevallen identificeren en het nieuwe platform onder load testen. Parallelbedrijf kan op verschillende manieren worden gerealiseerd:

• Read-only-replica voor reporting/BI-voorbereiding
• „Dual write“ in gedefinieerde deelgebieden (alleen als dit goed beheersbaar is)
• Stichtagsmigratie met meerdere dry-runs en een heldere cutover-checklist

Belangrijk is de complexiteit niet te overschrijden: dual-write klinkt aantrekkelijk, maar is foutgevoelig als vaklogica niet gecentraliseerd is. Vaak is een herhaalbare stichtagsrun met goede validatie uiteindelijk economischer.

Fase 4: optimalisatie, integriteit, performance, operationele processen

Na de cutover begint de fase waarin MariaDB zijn sterktes moet tonen: referentiële integriteit, performante indexen, nette rechten, monitoring, backup/restore-tests. Hier worden vaak pas de „echte“ productielasten zichtbaar: lange rapporten, slecht geïndexeerde zoekmaskers, batch-updates. Een gecontroleerde migratie plant deze fase expliciet in, in plaats van haar als onvoorziene nabehandeling te laten ontstaan.

Datatypes en mapping: van Paradox naar MariaDB zonder informatieverlies

Het veldmapping is het hart van de migratie. Typische toewijzingen (vereenvoudigd) zijn:

• Alpha / Memo: VARCHAR/TEXT (met utf8mb4), lengtechecks en trim-regels
• Number: INT/BIGINT/DECIMAL afhankelijk van het waardebereik; voorzichtigheid bij impliciete decimalen
• Date/Time: DATE/DATETIME/TIMESTAMP; duidelijke regels voor „0-datum“ of NULL
• Logical: BOOLEAN respectievelijk TINYINT(1) met eenduidige semantiek
• Currency: DECIMAL(…,2/4) in plaats van float om afrondingsfouten te voorkomen

Belangrijk is niet alleen datatypes te vertalen, maar ook vakregels vast te leggen: mag een veld NULL zijn? Welke defaultwaarden zijn vakinhoudelijk correct? Welke combinaties moeten uniek zijn? Hieruit volgen constraints en indexen. Deze regels waren in het Paradox/BDE-systeem vaak impliciet in de UI of in code verborgen – in MariaDB moeten ze, waar zinvol, expliciet worden gemaakt.

Integriteit: primary keys, foreign keys en unieke indexen overnemen

Veel legacy-databases functioneren jarenlang zonder referentiële integriteit – totdat integraties, portals of parallelle processen erbij komen. Op dat moment wordt datakwaliteit vaak het beperkende factor. In MariaDB kunnen foreign keys, unique constraints en checks (afhankelijk van versie/engine) worden ingezet om datapunten vroegtijdig te blokkeren.

Een praktische aanpak is integriteit stapsgewijs in te voeren:

• Eerst primary keys en unieke indexen op kernobjecten (klanten, artikelen, documenten)
• Daarna foreign keys in de stabiele gebieden
• Voor „historische“ tabellen met datarommel: eerst opschonen, daarna constraints

Dat verlaagt het risico dat de cutover op erfenissen strandt en verbetert toch duidelijk de algehele toestand.

Performance in de praktijk: wat verandert met MariaDB

Paradox/BDE-systemen zijn vaak geoptimaliseerd voor „bestandssnelheid“: lokale indexen, snelle table-access, veel client-side filtering. Bij MariaDB verschuift het werk naar de server. Dat is positief, maar vereist wel nette SQL- en indexstrategieën.

Typische performance-valkuilen

• SELECT * uit grote tabellen, omdat dit vroeger „lokaal“ snel genoeg was
• Client-side filteren in plaats van server-side WHERE-clauses
• Ontbrekende samengestelde indexen op zoekmaskervelden (bijv. mandant + status + datum)
• LIKE ‚%tekst%‘ zonder geschikte fulltext-strategie

Meetbaar verbeteren in plaats van „op gevoel“

Een gecontroleerde migratie introduceert vroeg meetpunten: slow query log, EXPLAIN-analyses, reproduceerbare loadtests. Dit is vooral belangrijk wanneer na de migratie aanvullende componenten gepland zijn, zoals een REST-server of een klantenportal, die nieuwe toegangspatronen genereert (veel kleine requests, paging, zoekendpoints).

Delphi-specifiek: BDE-vervanging, FireDAC en nette toegangslagen

In Delphi-projecten is technische modernisering nauw verbonden met de dataaccess. De BDE is niet alleen „een driver“, maar een compleet toegangspatroon (TTable, recordgebaseerd, navigeren, lokale filters). Een migratie naar MariaDB is het juiste moment om de toegang te consolideren.

Van „DataSets overal“ naar gecontroleerde dataaccess

Veel applicaties hebben in elk formulier eigen queries. Dat schaalt slecht, zowel inhoudelijk als qua security. Beproefd is overstappen richting:

• Centrale repository-/service-klassen voor kernobjecten
• Eenduidige fout- en transactieverwerking
• Geparameteriseerde queries (SQL-injectie vermijden, plan-caching benutten)
• Configureerbare connection-pools of connection-management voor services

Daardoor ontstaat een basis voor een Layer-3-architectuur waarin UI, vaklogica en persistentie netjes gescheiden zijn. Dat helpt niet alleen bij de databasewisseling, maar ook bij latere uitbreiding richting REST-server of achtergronddiensten.

MariaDB-aansluiting met FireDAC: wat typisch te regelen is

In projecten komen steeds dezelfde vragen naar boven: welke dri ver-variant (MySQL/MariaDB), welke SSL-opties, welke timezone- en datuminstellingen, welke Unicode-settings? Dit zijn geen details, omdat ze directe invloed hebben op dataconsistentie (datum/tijd), sortering en operationele betrouwbaarheid (TLS). Een gecontroleerde migratie legt deze parameters vast, documenteert ze en test ze met realistische data.

Cutover-plan: stichtag, datafreeze, rollback – zonder verrassingen

De cutover is een project op zich. Een goed cutover-plan beschrijft niet alleen „wanneer omschakelen“, maar ook de beschermende maatregelen:

• Datafreeze: Vanaf wanneer worden er in het oude systeem geen gegevens meer vastgelegd? Zijn er noodprocessen?
• Finale import: Hoe lang duurt die realistisch? (Dry-runs leveren cijfers.)
• Validatie: Welke checks moeten groen zijn voor vrijgave (counts, totalen, steekproeven, vakreports)?
• Rollback: Wanneer wordt afgebroken en hoe gaat het daarna verder?
• Communicatie: Wie geeft vrij? Wie is in de war room bereikbaar?

Juist bij het MKB is een „rollback“ vaak niet technisch maar organisatorisch kritisch. Daarom moet de migratie zo voorbereid zijn dat de cutover geen experiment is, maar een geproefde procedure.

Na de migratie: basis voor REST, services en multiplatform

Wanneer MariaDB stabiel draait en de BDE-vervanging netjes is uitgevoerd, ontstaan nieuwe opties: REST-API’s voor externe systemen, achtergrondverwerking als Windows- of Linux-services, ontkoppeling van UI en vaklogica en perspectivisch multiplatform-clients. Een veelvoorkomende volgende stap is het uit de desktop halen van vaklogica, om integraties (ERP/DMS/CRM) en portals gecontroleerd te bedienen.

Belangrijk is: een REST-server is geen „extra laag“, maar een architectuurbeslissing. Wie dataaccess, validatie en rechten al in services/repositories geconsolideerd heeft, kan veel eenvoudiger robuuste API’s opbouwen.

Praktijk-checklist: wat u voor projectstart moet verduidelijken

• Welke modules zijn bedrijfskritisch en moeten op de cutover-dag gegarandeerd werken?
• Hoe zien echte datavolumes eruit (tabelgroottes, groei, archiefconcepten)?
• Welke rapporten moeten 1:1 identiek zijn, welke mogen verbeterd worden?
• Welke integraties hangen aan het systeem (bestandsexports, ODBC, Office, druktrajecten)?
• Is er multitenancy en zo ja: hoe is die vandaag afgebeeld?
• Welke operationele eisen gelden (backup-window, restore-tijd, rechten, audit)?

Deze verduidelijkingen zijn geen bureaucratie, maar voorkomen dat een migratie „technisch klaar“ is maar vakinhoudelijk niet wordt goedgekeurd.

Conclusie: gecontroleerd migreren betekent risico’s beheersbaar maken

Paradox en BDE gecontroleerd naar MariaDB migreren betekent de applicatie als totaal systeem moderniseren: datamodel, SQL, transacties, tekencoderingen, toegangslagen en operationele processen. Wie de wissel als een zuivere export ziet, krijgt meestal precies de problemen terug die men eigenlijk wilde oplossen – alleen nu op een nieuwe server.

Een stapsgewijze aanpak met reproduceerbare import, helder veldmapping, vroege validatie en een duidelijke BDE-vervanging (bijv. via FireDAC) creëert daarentegen een stabiele basis: voor meergebruikerswerking, voor integraties, voor services en voor de volgende stappen van de Delphi Modernisierung.

Als u uw migratie vakinhoudelijk veilig wilt plannen en zonder bedrijfsstilstand wilt uitvoeren, bespreken we graag de uitgangssituatie, risico’s en een realistisch fasenplan: https://net-base-software-gmbh.de/kontakt/