Migrar Paradox i BDE de manera controlada a MariaDB

Moltes aplicacions sectorials basades en Delphi s’han desenvolupat amb taules Paradox i la Borland Database Engine (BDE), perquè en aquella època era un estàndard pragmàtic: local, ràpid d’arrencar, amb poca infraestructura. A la pràctica, aquests sistemes sovint segueixen en producció fins avui —incloent reporting, impressió d’etiquetes, import/export, tasques per lots, taules d’històric i lògica especial que s’ha anat «mésclant» a l’accés a dades al llarg d’anys. Precisament per això una migració no és només una exportació de dades, sinó una reestructuració controlada: cal considerar conjuntament el model de dades, el comportament SQL, els efectes al codi i els processos d’operació.

MariaDB sovint és una molt bona opció com a plataforma objectiu quan es necessita un funcionament multiusuari robust, transaccions netes, còpies de seguretat centrals, replicació, una gestió d’accessos clara i la possibilitat de connectar portals web, serveis o APIs REST. El repte rarament és la instal·lació de la base de dades: l’esforç real està en el camí de migració segur: com es transfereixen correctament taules, índexs, claus primàries, conjunts de caràcters, camps de data, valors «buits» i relacions referencials sense trencar la lògica sectorial en funcionament?

Aquest article descriu un procediment provat per migrar Paradox i BDE cap a MariaDB de manera controlada: amb fonament tècnic, per etapes i amb enfocament en l’estabilitat. L’objectiu és una base sòlida per a passos de modernització posteriors —per exemple l’eliminació de BDE, el canvi a una BDE-Ablösung mit nativer Anbindung, una Layer-3 Architektur clara, REST-Server i clients multiplataforma.

Per què la migració Paradox/BDE és més que un canvi de base de dades

Paradox com a format de fitxer i BDE com a capa d’accés formen un sistema global amb peculiaritats que no convé reproduir 1:1 a MariaDB. Símptomes típics en el dia a dia són:

• Dependències opaques: les sentències SQL estan disperses (Forms, DataModules, Reports, SQL dinàmic en strings), sovint sense governança centralitzada.
• Comportament «per sensació»: certs filtres, ordres o joins funcionen de manera casual perquè Paradox/BDE és tolerant o fa conversions implícites de tipus.
• Limitacions multiusuari: bloquejos basats en fitxers, degradacions de rendiment a la xarxa, problemes de locking amb l’augment del volum de dades.
• Riscos de manteniment: dependències de BDE, controladors antics, desplegament difícil en versions modernes de Windows, qüestions 64‑bit/ARM64.

Una migració controlada no tracta aquests punts com a efectes col·laterals, sinó que els defineix com a criteris d’èxit. MariaDB no serà només la «nova base de dades», sinó l’oportunitat per desacoblar la capa d’accés a dades, augmentar la integritat funcional i habilitar interfícies.

Visió objectiu: MariaDB com a base de dades estable per a escriptoris, serveis i portals

Una visió raonable per a aplicacions B2B acostuma a constar de tres capes:

• Base de dades (MariaDB): manteniment de dades consistent, índexs, constraints, transaccions, usuaris/rols, backups.
• Lògica de negoci (Server/Services): validacions, fluxos de treball, importadors, scheduler, interfícies. Opcionalment com a REST-Server, Windows- o Linux-Services.
• Clients (VCL/FMX/Web): interfícies d’usuari, informes, components offline, integracions. Idealment amb contractes clars respecte la lògica de negoci.

Segons la situació d’origen no cal implementar-ho tot de cop. Però la migració hauria de planificar-se de manera que no obstaculitzi el camí cap a una arquitectura neta. Qui avui només copia taules i demà torna a «accedir directament» a la base de dades des de cada formulari haurà introduït MariaDB, però els riscos reals romandran.

Inventari: què cal migrar realment

Al començament cal una presa d’inventari que vagi més enllà del «quantes taules hi ha». En projectes Paradox/BDE és habitual que la base de dades sigui només una part de la veritat. Punts rellevants:

1) Taules, índexs, «claus pseudo»

Sovint falten claus primàries reals. En lloc d’això hi ha combinacions de camps, números seqüencials sense constraint inequívoc o camps «Key» mantinguts per l’aplicació. A MariaDB això ha de convertir-se en claus úniques i fiables —si no, transaccions i integritat referencial només seran parcialment efectives.

2) Consultes, blocs SQL dinàmics, informes

BDE utilitza diferents dialectes SQL segons la component i tolera sentències «creatives». Les eines de reporting (fins i tot antigues) sovint incorporen definicions SQL pròpies. La migració ha d’identificar i categoritzar aquestes fonts: consultes nucli crítiques, informes poc usats, imports especials.

3) Conjunt de caràcters i caràcters especials (Umlauts, ISO/ANSI, Unicode)

Moltes aplicacions Paradox són històricament basades en ANSI. Si l’aplicació Delphi es va migrar parcialment a Unicode poden aparèixer entorns mixtos: dades en un encoding antic, UI en Unicode, exports que esperen Windows-1252. MariaDB ha de tenir un concepte clar aquí (típicament utf8mb4), incloent conversió neta i proves per detectar errors «invisibles» (comparacions, ordenació, Trim/Pad, caràcters especials).

4) Valors «buits», lògica NULL i camps de data

Paradox/BDE conegut per diversos casos especials: cadenes buides en lloc de NULL, dates 0, timestamps «buits», valors per defecte que es generen a la UI. MariaDB distingeix estrictament entre NULL i buit. Això afecta claus WHERE, agregacions i càlculs. Aquestes diferències cal avaluar-les per taula/camp.

5) Artefactes secundaris: taules de sessió, configuració local, cache

Sovint la estructura Paradox conté taules locals per a resultats intermedis, búfers d’exportació, dissenys d’usuari o paràmetres. Algunes dades han de romandre locals (p.ex. layouts d’UI), altres han d’estar centralitzades (p.ex. processos de treball, estats, logs). La migració és una oportunitat per separar aquestes categories de manera neta.

Pitfalls en Paradox/BDE: diferències tècniques típiques

Per fer la migració planificable val la pena abordar explícitament les diferències recurrents.

Dialecte SQL i operadors

El SQL de BDE/Paradox no és idèntic al de MySQL/MariaDB. Hi ha diferències en funcions de data, funcions de cadena, outer joins (històricament), la lògica LIKE/mascaretes i en conversions implícites de tipus. Un enfocament controlat substitueix el «ja funciona» per regles clares: quines sentències es porten, quines es reescriuen deliberadament, quines s’encapsulen en vistes/procediments emmagatzemats (si té sentit).

Ordenació i collation

A Paradox les ordres i consideracions de majúscules/minúscules sovint difereixen de MariaDB, especialment amb umlauts. A MariaDB la collation (p. ex. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) determina comparació i ordenació. No és una qüestió acadèmica: afecta la deduplicació, funcions de cerca i el comportament de constraints Unique.

Autoincrement i sèries de numeració

Paradox té camps autoincrement, però sovint les aplicacions utilitzen sèries pròpies (números de document, números de comanda) amb lògica especial. A MariaDB cal separar clarament:

• Clau primària tècnica: AUTO_INCREMENT (o UUID, segons l’arquitectura) per a relacions.
• Número funcional: sèrie pròpia amb protecció transaccional, possiblement per client/període.

Qui intenta fer servir un número funcional com a clau tècnica es pot trobar amb reformes costoses després.

Locking i transaccions

El salt d’un accés basat en fitxers a un servidor real és un benefici, però canvia el comportament. A MariaDB les transaccions (InnoDB) són centrals. Cal decidir on s’estableixen els límits transaccionals: per diàleg, per operació d’emmagatzematge, per batch. Especialment crític és l’ús de transaccions llargues i el «mode edició» durant minuts, que és comú en entorns Paradox però problemàtic en servidor (locks, deadlocks, retard de replicació). Sovint una adaptació de la forma de treball o de la UI forma part de la migració.

Model de treball: migració controlada per etapes en lloc d’un Big Bang

En entorns B2B la estabilitat operativa acostuma a ser més important que un tall ràpid. Un camí de migració per etapes redueix el risc perquè l’àrea funcional i TI poden validar iterativament.

Etapa 1: transferència del model de dades amb mapping, sense canvis al codi

En el primer pas es crea un esquema MariaDB que reprodueixi l’estructura Paradox —però ja aplicant principis d’objectiu: claus primàries, índexs, tipus de dada adequats, utf8mb4, InnoDB. En paral·lel es desenvolupa un procés d’import reproducible (scripts/eines) que es pot repetir si cal. La repetibilitat és crítica perquè una migració rarament es completa a la primera passada.

Els entregables d’aquesta etapa solen ser:

• Definició d’esquema (DDL) versionada (p. ex. en Git)
• Llista de mapeig de camps (Paradox → MariaDB) incloent regles de conversió
• Procediment d’import amb registre (nombre de registres, errors, valors fora de rang)
• Primeres validacions (comptes, sumes, checksums)

Etapa 2: Eliminació de BDE en l’accés a dades (p. ex. amb FireDAC)

El pas real de modernització és desacoblar-se de BDE. En projectes Delphi BDE-Ablosung mit nativer Anbindung és un camí proveït, perquè ofereix controladors moderns, transaccions, binding de paràmetres i components uniformes per a diversos backends SQL. El crucial no és tant «treure BDE», sinó com queda el codi després: accés a dades centralitzat, maneig d’errors clar, paràmetres nets en comptes de concatenació de strings.

Tasques típiques en aquesta etapa:

• Substituir TTable/TQuery per queries i DataSets basats en FireDAC
• Introduir una capa d’accés a dades (DAL) com a base per a una Layer-3 arquitectura
• Estandarditzar els àmbits transaccionals (Commit/Rollback)
• Revisió SQL: adaptació de dialecte, paràmetres, paginació, joins

Si la seva aplicació s’ha de modernitzar a llarg termini, aquest pas sovint és més important que la mera migració de dades. Proporciona la llibertat tècnica per a 64‑bit, versions modernes de Windows i pipelines de desplegament nets.

Etapa 3: funcionament paral·lel i aprovació funcional sense interrupcions de servei

Per a sistemes crítics és recomanable un funcionament paral·lel: MariaDB es construeix i s’alimenta cíclicament (o incrementalment) mentre el sistema antic continua actiu. Això permet que l’àrea funcional compari resultats, identifiqui casos marginals i proveï l’ergonomia sota càrrega. El funcionament paral·lel es pot implementar de diverses maneres:

• Rèplica en mode només lectura per a reporting/BI
• «Dual Write» en parts definides (només si està ben controlat)
• Migració en una data de tall amb diversos assajos i una checklist clara per al cutover

És important no sobredimensionar la complexitat: Dual-Write pot semblar atractiu però és propens a errors si la lògica funcional no està centralitzada. Sovint un procés de tall repetible amb bona validació resulta més econòmic al final.

Etapa 4: optimització, integritat, rendiment, processos d’operació

Després del cutover comença la fase on MariaDB ha de demostrar les seves fortaleses: integritat referencial, índexs rendibles, permisos nets, monitoratge, proves de backup/restore. Aquí apareixen sovint les càrregues «reals» de producció: informes llargs, màscares de cerca mal indexades, actualitzacions per lots. Una migració controlada planifica explícitament aquesta etapa en lloc de deixar-la com a retrallada no prevista.

Tipus de dades i mapping: de Paradox a MariaDB sense pèrdua d’informació

El mapeig de camps és el nucli de la migració. Assignacions típiques (simplificades) són:

• Alpha / Memo: VARCHAR/TEXT (amb utf8mb4), comprovacions de longitud i regles de trim
• Number: INT/BIGINT/DECIMAL segons el rang de valors; precaució amb decimals implícits
• Date/Time: DATE/DATETIME/TIMESTAMP; regles clares per a «data 0» vs. NULL
• Logical: BOOLEAN o TINYINT(1) amb semàntica inequívoca
• Currency: DECIMAL(…,2/4) en lloc de float per evitar errors d’arrodoniment

És important no només traduir tipus, sinó també documentar regles funcionals: un camp pot ser NULL? Quins valors per defecte són correctes des del punt de vista funcional? Quines combinacions han de ser úniques? Això deriva en constraints i índexs. Sovint aquestes regles estaven implícites a la UI o al codi en el sistema Paradox/BDE —a MariaDB han de ser explícites quan té sentit.

Integritat: portar claus primàries, claus foranes i índexs únics

Moltes bases de dades legades han funcionat anys sense integritat referencial —fins que apareixen integracions, portals o processos paral·lels. En aquell moment la qualitat de dades es converteix en factor limitant. A MariaDB es poden utilitzar Foreign Keys, Unique Constraints i CHECKs (segons versió/engine) per evitar errors de dades de forma precoç.

Un camí pràctic és introduir la integritat per fases:

• Primer les claus primàries i índexs únics en objectes clau (clients, articles, documents)
• Després les Foreign Keys en les àrees estables
• Per a taules «històriques» amb dades brutes: primer neteja, després constraints

Això redueix el risc que el cutover fracassi per culpa d’elements antics i millora substantivament la situació global.

Rendiment a la pràctica: què canvia amb MariaDB

Els sistemes Paradox/BDE sovint estan optimitzats per «velocitat de fitxer»: índexs locals, accés ràpid a taules, molta filtració al client. Amb MariaDB la feina es trasllada al servidor. Això és positiu, però exigeix estratègies netes d’SQL i índexs.

Trampes de rendiment típiques

• SELECT * des de taules grans perquè abans «localment» era prou ràpid
• Filtrat al client en lloc de WHERE al servidor
• Falta d’índexs compostos per a camps de cerca (p. ex. client + estat + data)
• LIKE ‚%text%‘ sense una estratègia de text complet adequada

Millorar de manera mesurable en comptes de «per sensació»

Una migració controlada estableix punts de mesura des del principi: Slow Query Log, anàlisis EXPLAIN, proves de càrrega reproductibles. Això és especialment important si després de la migració es preveu afegir components com un servidor REST o un portal de clients que genera nous patrons d’accés (moltes peticions petites, paginació, endpoints de cerca).

Específic per a Delphi: eliminació de BDE, FireDAC i capes d’accés netes

En projectes Delphi la modernització tècnica està estretament lligada a l’accés a dades. BDE no és només «un driver», sinó un estil d’accés complet (TTable, basat en registres, navegació, filtres locals). Migrar a MariaDB és el moment adequat per consolidar l’accés.

De «DataSets a tot arreu» a accés a dades controlat

Molt sovint cada formulari té les seves pròpies consultes. Això no escala ni funcionalment ni des del punt de vista de seguretat. Un enfocament provat és migrar cap a:

• Classes repository/service centrals per als objectes clau
• Maneig uniformat d’errors i transaccions
• Consultes parametritzades (evitar SQL Injection, aprofitar cache de plans)
• Gestió de connexions configurable o pools per a serveis

Això crea la base per a una Layer-3 arquitectura en què UI, lògica de negoci i persistència estan separades. Això no només facilita el canvi de base de dades, sinó també l’evolució cap a un REST-Server o serveis de fons.

Connexió MariaDB amb FireDAC: qüestions típiques a definir

En projectes reapareixen constantment les mateixes preguntes: quina variant del driver (MySQL/MariaDB), quines opcions SSL, quines configuracions de zona horària i data, quins paràmetres Unicode? No són detalls perquè afecten directament la consistència de dades (data/hora), l’ordenació i la seguretat operativa (TLS). Una migració controlada fixa aquests paràmetres, els documenta i els prova amb dades realistes.

Pla de cutover: data de tall, congelació de dades, rollback — sense sorpreses

El cutover és un projecte en si mateix. Un bon pla de cutover no només indica «quan fer el tall», sinó també mesures de protecció:

• Congelació de dades: en quin moment l’antic sistema deixa d’acceptar dades? Hi ha processos d’emergència?
• Import final: quant de temps trigarà realment? (assajos prèvis donen números.)
• Validació: quines comprovacions han d’estar verdes abans d’autoritzar el pas (comptes, sumes, mostres, informes funcionals)?
• Rollback: quin és el punt d’abandonament i quin és el procediment posterior?
• Comunicació: qui autoritza? qui és al war room?

En entorns mitjans un «rollback» sovint no és només tècnic sinó organitzatiu. Per això la migració ha d’estar tan preparada que el cutover no sigui un experiment sinó una execució provada.

Després de la migració: base per a REST, serveis i multiplataforma

Quan MariaDB funcioni de manera estable i l’eliminació de BDE s’hagi executat correctament, s’obren noves opcions: APIs REST per a sistemes externs, processament en segon pla com a serveis Windows o Linux, desacoblament de UI i lògica de negoci i, a la llarga, clients multiplataforma. Sovint el pas següent és extreure la lògica de negoci del client d’escriptori per atendre integracions (ERP/DMS/CRM) i portals de manera controlada.

Cal tenir present: un REST-Server no és una «capa addicional», sinó una decisió arquitectònica. Qui ja hagi consolidat l’accés a dades, validacions i permisos en serveis/repositories podrà desenvolupar APIs robustes molt més fàcilment.

Checklist pràctic: què aclarir abans d’iniciar el projecte

• Quins mòduls són crítics per al negoci i han d’estar operatius el dia del cutover?
• Quins són els volums de dades reals (grandària de taules, creixement, conceptes d’arxiu)?
• Quins informes han de ser idèntics 1:1 i quins es poden millorar?
• Quines integracions depenen del sistema (exports de fitxers, ODBC, Office, canals d’impressió)?
• Hi ha una capacitat multiempresa i, en cas afirmatiu, com està representada avui?
• Quins requisits operatius s’apliquen (finestra de backups, temps de restauració, permisos, auditoria)?

Aquests aclariments no són burocràcia; eviten que una migració sigui «tècnicament acabada» però no acceptada des del punt de vista funcional.

Conclusió: migrar de manera controlada significa fer gestionables els riscos

Migrar Paradox i BDE cap a MariaDB de manera controlada vol dir modernitzar l’aplicació com a sistema global: model de dades, SQL, transaccions, conjunts de caràcters, capa d’accés i processos operatius. Qui tracta el canvi com un simple export sol obtenir precisament els problemes que volia eliminar —ara en un servidor nou.

Un procediment per etapes amb import reproducible, mapeig de camps net, validació primerenca i una eliminació clara de BDE (p. ex. mitjançant FireDAC) proporciona, en canvi, una base estable: per a operació multiusuari, integracions, serveis i següents passos de la Delphi Modernisierung.

Si voleu planificar la vostra migració amb seguretat funcional i sense interrupcions de servei, parlem amb gust de la situació d’origen, dels riscos i d’un pla d’etapes realista: https://net-base-software-gmbh.de/kontakt/