Migrer Paradox et BDE vers MariaDB de manière contrôlée

De nombreuses applications métiers Delphi ont été développées avec des tables Paradox et la Borland Database Engine (BDE), car c’était à l’époque un standard pragmatique : local, prêt à l’emploi, peu d’infrastructure. Dans la pratique, ces systèmes restent souvent en production jusqu’à aujourd’hui — incluant reporting, impression d’étiquettes, import/export, jobs batch, tables d’historique et logique métier particulière qui s’est « incrustée » dans l’accès aux données au fil des ans. C’est précisément pourquoi une migration n’est pas qu’un export de données, mais une refonte contrôlée : modèle de données, comportement SQL, effets secondaires dans le code et processus d’exploitation doivent être considérés ensemble.

MariaDB est souvent un très bon choix comme plateforme cible lorsqu’il s’agit d’un fonctionnement multi‑utilisateur robuste, de transactions propres, de sauvegardes centralisées, de réplication, d’une gestion claire des droits et de la capacité de se connecter à des portails Web, des services ou des APIs REST. La difficulté n’est généralement pas l’installation de la base de données — l’effort réel réside dans la voie de migration sûre : comment transférer correctement tables, index, clés primaires, jeux de caractères, champs date, valeurs « vides » et relations référentielles sans casser la logique métier en production ?

Cet article décrit une approche éprouvée pour migrer Paradox et BDE vers MariaDB de manière contrôlée : techniquement fondée, par étapes et axée sur la stabilité. L’objectif est de fournir une base solide pour d’autres étapes de modernisation — par exemple le remplacement de BDE, la migration vers une remplacement de BDE avec une connexion native, une architecture Layer-3 claire, des serveurs REST et des clients multiplateforme.

Pourquoi la migration Paradox/BDE est plus qu’un simple changement de base de données

Paradox en tant que format de fichier et BDE en tant que couche d’accès forment un système global avec des particularités qu’il ne faut pas reproduire à l’identique dans MariaDB. Les symptômes typiques rencontrés au quotidien sont :

• Dépendances opaques : les instructions SQL sont dispersées (Forms, DataModules, Reports, SQL dynamique sous forme de chaînes), souvent sans gouvernance centrale.
• Comportement « au doigt mouillé » : certains filtres, tris ou jointures fonctionnent par hasard parce que Paradox/BDE est tolérant ou effectue des conversions de type implicites.
• Limites multi‑utilisateurs : verrous basés sur des fichiers, dégradations de performance sur le réseau, problèmes de locking avec l’augmentation du volume de données.
• Risques de maintenance : dépendances à BDE, anciens drivers, déploiement délicat sur des versions modernes de Windows, questions 64‑bit/ARM64.

Une migration contrôlée prend ces points pour critères objectifs, pas comme effets secondaires. MariaDB n’est alors pas seulement une « nouvelle base de données », mais l’occasion de découpler la couche d’accès aux données, d’accroître l’intégrité métier et d’assurer l’interopérabilité.

Vision cible : MariaDB comme socle stable pour desktop, services et portails

Une vision cible pertinente pour des applications métiers B2B se compose généralement de trois niveaux :

• Base de données (MariaDB) : tenue de données cohérente, index, contraintes, transactions, utilisateurs/roles, sauvegardes.
• Logique métier (Server/Services) : validations, workflows, importeurs, scheduler, interfaces. Optionnellement sous forme de serveur REST, Windows- ou Linux-services.
• Clients (VCL/FMX/Web) : interfaces utilisateur, rapports, parties hors‑ligne, intégrations. Idéalement avec des contrats clairs envers la logique métier.

Selon l’état initial, tout n’a pas besoin d’être mis en œuvre immédiatement. Mais la migration doit être planifiée de façon à ne pas obstruer la voie vers une architecture propre. Qui aujourd’hui se contente de copier des tables puis réintroduit demain des accès directs depuis chaque formulaire vers la base aura certes MariaDB, mais les risques réels subsisteront.

Inventaire : ce qui doit réellement être migré

Tout commence par un inventaire qui dépasse la seule question du « nombre de tables ». Dans les projets Paradox/BDE, il est fréquent que la base de données ne soit qu’une partie de la vérité. Points importants :

1) Tables, index, « pseudo‑clés »

Des Primary Keys réelles font souvent défaut. À la place existent des combinaisons de champs, des numéros séquentiels sans contrainte unique ou des champs « Key » gérés par l’application. Pour MariaDB, il faut en faire des clés uniques et robustes — sinon transactions et intégrité référentielle ne seront que partiellement efficaces.

2) Requêtes, blocs SQL dynamiques, rapports

BDE utilise selon les composants des dialectes SQL différents et tolère des instructions « créatives ». Les composants de reporting (même anciens) contiennent souvent leurs propres définitions SQL. Une migration doit repérer et catégoriser ces sources : requêtes cœur critiques, analyses rarement utilisées, imports spéciaux.

3) Jeu de caractères et caractères spéciaux (umlauts, ISO/ANSI, Unicode)

Beaucoup d’applications Paradox sont historiquement basées sur ANSI. Si l’application Delphi a été convertie au fil du temps vers Unicode, des mondes mixtes apparaissent : données en ancien encodage, UI en Unicode, exports qui attendent Windows‑1252. MariaDB doit recevoir un concept clair (typiquement utf8mb4), incluant une conversion propre et des tests contre des erreurs « invisibles » (comparaisons, tri, trim/pad, caractères spéciaux).

4) Valeurs « vides », logique NULL et champs date

Paradox/BDE connaît divers cas particuliers : chaînes vides au lieu de NULL, dates à 0, timestamps « vides », valeurs par défaut générées par l’UI. MariaDB distingue strictement NULL et vide. Cela affecte les clauses WHERE, les agrégations et les calculs. Ces différences doivent être évaluées par table/champ.

5) Artefacts annexes : tables de session, configuration locale, cache

Souvent la structure Paradox contient des tables locales pour résultats intermédiaires, buffers d’export, layouts utilisateur ou paramètres. Certaines données doivent rester locales (p. ex. layouts UI), d’autres centralisées (p. ex. opérations de travail, statuts, logs). Une migration est l’occasion de séparer proprement ces catégories.

Pièges courants avec Paradox/BDE : différences techniques typiques

Pour rendre la migration planifiable, il est utile d’adresser explicitement les différences récurrentes.

Dialecte SQL et opérateurs

Le SQL Paradox/BDE n’est pas identique au SQL MySQL/MariaDB. Des différences apparaissent notamment pour les fonctions date, fonctions de chaîne, outer joins (historiquement), la logique Like/masques et les conversions de type implicites. Une approche contrôlée remplace le « ça marche » par des règles claires : quelles instructions sont portées, quelles sont réécrites délibérément, lesquelles sont encapsulées dans des vues/procédures stockées (si pertinent) ?

Tri et collation

Dans Paradox, l’ordre de tri et la sensibilité à la casse diffèrent souvent de MariaDB, en particulier pour les umlauts. Dans MariaDB, la collation (p. ex. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) détermine comparaison et tri. Ce n’est pas un détail académique : cela influence la déduplication, les fonctions de recherche et le comportement des contraintes UNIQUE.

Autoincrement et séries de numéros

Paradox propose des champs Autoincrement, mais les applications utilisent fréquemment leurs propres séries numériques (numéros de pièces, numéros de commande) avec une logique spécifique. Dans MariaDB il convient de séparer clairement :

• Clé primaire technique : AUTO_INCREMENT (ou UUID selon l’architecture) pour les relations.
• Numéro métier : série propre protégée par transaction, éventuellement par mandant/période.

Tenter d’utiliser un numéro métier comme clé technique conduit à des refontes coûteuses ultérieurement.

Verrouillage et transactions

Le passage d’un accès basé sur fichiers à un vrai serveur est un gain, mais change les comportements. Dans MariaDB les transactions (InnoDB) sont centrales. Il faut décider où placent les frontières transactionnelles : par dialogue, par opération d’enregistrement, par batch. Important : les transactions longues et les « modes édition » de plusieurs minutes sont fréquents en environnement Paradox, mais problématiques côté serveur (locks, deadlocks, retard de réplication). Adapter les méthodes de travail ou l’interface est souvent partie intégrante de la migration.

Modèle d’intervention : migration contrôlée par étapes plutôt que Big Bang

En environnement B2B, la stabilité opérationnelle prime souvent sur une coupure rapide. Un chemin de migration par étapes réduit les risques, car métiers et IT peuvent valider de façon itérative.

Étape 1 : transfert du modèle de données avec mapping, sans refonte du code

La première étape consiste à créer un schéma MariaDB qui reflète la structure Paradox — mais selon des principes cibles : Primary Keys, index, types de données appropriés, utf8mb4, InnoDB. En parallèle on met en place un processus d’import reproductible (scripts/outils) réexécutable si nécessaire. La répétabilité est essentielle, car la migration n’est jamais « parfaite » au premier passage.

Livrables typiques de cette étape :

• Définition du schéma (DDL) versionnée (p. ex. dans Git)
• Liste de mapping des champs (Paradox → MariaDB) incluant règles de conversion
• Procédure d’import avec journalisation (nombre d’enregistrements, erreurs, valeurs aberrantes)
• Premiers rapports de validation (comptages, sommes, checksums)

Étape 2 : remplacement de BDE dans l’accès aux données (p. ex. avec FireDAC)

La vraie étape de modernisation est le découplage de BDE. Dans les projets Delphi, BDE-Ablosung mit nativer Anbindung est une voie éprouvée, car il apporte des drivers modernes, transactions, binding de paramètres et des composants homogènes pour différents backends SQL. L’essentiel n’est pas de « retirer BDE », mais la manière dont le code se présente ensuite : accès aux données centralisé, gestion claire des erreurs, paramètres propres plutôt que concaténation de chaînes.

Tâches typiques de cette étape :

• Remplacer TTable/TQuery par des queries et DataSets FireDAC
• Introduire une couche d’accès aux données (DAL) comme base pour une architecture Layer-3 future
• Standardiser les scopes transactionnels (Commit/Rollback)
• Revue SQL : adaptation de dialecte, paramètres, pagination, joins

Si votre application doit être modernisée sur le long terme, cette étape est souvent plus décisive que la seule migration des données. Elle crée la liberté technique pour le 64‑bit, des versions modernes de Windows et des pipelines de déploiement propres.

Étape 3 : exploitation parallèle et validation métier sans interruption

Pour les systèmes critiques, un fonctionnement parallèle est judicieux : MariaDB est alimentée en cycles (ou de manière incrémentale) tandis que le système legacy continue de tourner. Le métier peut comparer les analyses, identifier les cas limites et tester la nouvelle plateforme sous charge. Le fonctionnement parallèle peut être mis en œuvre de différentes façons :

• Réplique en lecture seule pour préparation reporting/BI
• « Dual Write » dans des domaines définis (uniquement si maîtrisé)
• Migration à date cible avec plusieurs dry‑runs et une checklist de cutover claire

Il est important de ne pas complexifier outre mesure : le dual‑write semble attractif mais est source d’erreurs si la logique métier n’est pas centralisée. Souvent un run répétable à date cible avec une validation solide est économiquement plus viable.

Étape 4 : optimisation, intégrité, performance, processus d’exploitation

Après le cutover débute la phase où MariaDB doit démontrer ses avantages : intégrité référentielle, index performants, droits clairs, monitoring, tests de backup/restore. C’est fréquemment à ce moment que les vraies charges de production se révèlent : rapports longs, masques de recherche mal indexés, mises à jour batch lourdes. Une migration contrôlée planifie explicitement cette étape plutôt que de la laisser devenir un correctif improvisé.

Types de données et mapping : de Paradox vers MariaDB sans perte d’information

Le mapping des champs est le cœur de la migration. Correspondances typiques (simplifiées) :

• Alpha / Memo : VARCHAR/TEXT (avec utf8mb4), contrôles de longueur et règles de trim
• Number : INT/BIGINT/DECIMAL selon l’étendue des valeurs ; vigilance sur des décimales implicites
• Date/Time : DATE/DATETIME/TIMESTAMP ; règles claires pour les « dates 0 » vs NULL
• Logical : BOOLEAN ou TINYINT(1) avec une sémantique claire
• Currency : DECIMAL(… ,2/4) au lieu de Float, pour éviter des erreurs d’arrondi

Il est essentiel de ne pas se limiter à traduire les types, mais aussi de documenter les règles métier : un champ peut‑il être NULL ? Quels sont les défauts métiers corrects ? Quelles combinaisons doivent être uniques ? De ces règles découlent contraintes et index. Ces règles étaient souvent implicites dans l’UI ou le code Paradox/BDE — dans MariaDB elles doivent, là où pertinent, devenir explicites.

Intégrité : reproduire Primary Keys, Foreign Keys et index uniques

Beaucoup de bases legacy ont fonctionné des années sans intégrité référentielle — jusqu’à l’arrivée d’intégrations, portails ou processus parallèles. À ce stade la qualité des données devient un facteur limitant. Dans MariaDB on peut utiliser Foreign Keys, contraintes UNIQUE et CHECKs (selon version/engine) pour prévenir les erreurs de données en amont.

Une approche pragmatique consiste à introduire l’intégrité par étapes :

• Ajouter d’abord Primary Keys et index uniques sur les objets centraux (clients, articles, pièces)
• Puis introduire les Foreign Keys dans les zones stables
• Pours les tables « historiques » contenant des données bruitées : nettoyer d’abord, puis appliquer les contraintes

Cela réduit le risque qu’un cutover échoue à cause d’anciennes dettes et améliore significativement l’état général.

Performance en pratique : ce qui change avec MariaDB

Les systèmes Paradox/BDE sont souvent optimisés pour la « vitesse fichier » : index locaux, accès rapide aux tables, beaucoup de filtrage côté client. Avec MariaDB la charge se déplace côté serveur. C’est positif, mais cela exige une stratégie SQL et d’indexation propre.

Pièges de performance typiques

• SELECT * sur de grandes tables, car localement c’était assez rapide
• Filtrage côté client au lieu de WHERE côté serveur
• Absence d’index composés pour les masques de recherche (p. ex. mandant + statut + date)
• LIKE ‚%texte%‘ sans stratégie de recherche plein‑texte adaptée

Améliorer de façon mesurable plutôt que « au feeling »

Une migration contrôlée établit tôt des points de mesure : slow query log, analyses Explain, tests de charge reproductibles. C’est particulièrement important si, après la migration, d’autres composants sont prévus, comme un serveur REST ou un portail client générant de nouveaux schémas d’accès (beaucoup de petites requêtes, pagination, endpoints de recherche).

Spécifique Delphi : remplacement de BDE, FireDAC et couches d’accès propres

Dans les projets Delphi, la modernisation technique est étroitement liée à l’accès aux données. BDE n’est pas simplement « un driver », mais un style d’accès complet (TTable, accès enregistrement par enregistrement, navigation, filtres locaux). La migration vers MariaDB est le bon moment pour consolider cet accès.

De « DataSets partout » à un accès aux données contrôlé

Beaucoup d’applications contiennent des queries propres à chaque formulaire. Cela ne scale ni fonctionnellement ni en sécurité. Une migration réussie tend vers :

• Classes repository/service centrales pour les objets clés
• Gestion uniforme des erreurs et des transactions
• Queries paramétrées (éviter SQL Injection, tirer parti du plan‑caching)
• Pools de connexions configurables ou gestion des connexions pour les services

On obtient ainsi une base pour une architecture Layer-3 où UI, logique métier et persistance sont séparées. Cela facilite non seulement le changement de base, mais aussi l’évolution vers des serveurs REST ou des services en arrière‑plan.

Connexion MariaDB avec FireDAC : points à clarifier

Dans les projets reviennent souvent les mêmes questions : quelle variante de driver (MySQL/MariaDB), quelles options SSL, quelles options timezone/date, quels réglages Unicode ? Ce ne sont pas des détails, car ils impactent directement la consistance des données (date/heure), le tri et la sécurité d’exploitation (TLS). Une migration contrôlée fixe ces paramètres, les documente et les teste sur des données réalistes.

Plan de cutover : date cible, gel des données, rollback — sans surprises

Le cutover est un projet à part entière. Un bon plan de cutover décrit non seulement « quand basculer », mais aussi les mesures de protection :

• Gel des données : à partir de quand le legacy n’accepte‑t‑il plus d’enregistrements ? Existe‑t‑il des procédures d’urgence ?
• Import final : combien de temps prend‑il réellement ? (les dry‑runs donnent des estimations)
• Validation : quels checks doivent être verts pour valider la mise en service (comptages, sommes, échantillonnages, rapports métier) ?
• Rollback : quand abandonner et quelle est la marche à suivre ?
• Communication : qui autorise la mise en service ? Qui est présent dans le war room ?

Dans les entreprises de taille moyenne, un « rollback » est souvent plus critique sur le plan organisationnel que technique. C’est pourquoi la migration doit être préparée pour que le cutover soit un processus répété et éprouvé, pas une expérimentation.

Après la migration : socle pour REST, services et multiplateforme

Lorsque MariaDB tourne de façon stable et que la suppression de BDE est réalisée proprement, de nouvelles options apparaissent : APIs REST pour systèmes externes, traitements background en tant que services Windows ou Linux, découplage de l’UI et de la logique métier et, à terme, clients multiplateformes. Le pas suivant fréquent est d’extraire la logique métier du desktop afin de gérer intégrations (ERP/DMS/CRM) et portails de manière contrôlée.

Important : un serveur REST n’est pas une « couche supplémentaire », mais un choix d’architecture. Qui a déjà consolidé accès aux données, validations et droits dans des services/repositories pourra exposer des APIs robustes beaucoup plus facilement.

Checklist pratique : points à clarifier avant le démarrage

• Quels modules sont critiques pour le métier et doivent impérativement fonctionner le jour du cutover ?
• Quels sont les volumes de données réels (taille des tables, croissance, concepts d’archivage) ?
• Quels rapports doivent être identiques à 1:1 et lesquels peuvent être améliorés ?
• Quelles intégrations dépendent du système (exports de fichiers, ODBC, Office, flux d’impression) ?
• Existe‑t‑il une gestion multi‑mandant, et si oui : comment est‑elle modélisée aujourd’hui ?
• Quelles exigences opérationnelles s’appliquent (fenêtre de backup, RTO, droits, audit) ?

Ces clarifications ne sont pas de la bureaucratie, elles évitent qu’une migration soit « techniquement terminée » mais refusée pour des raisons fonctionnelles.

Conclusion : migrer de façon contrôlée, c’est rendre les risques gérables

Migrer Paradox et BDE vers MariaDB de manière contrôlée revient à moderniser l’application comme système complet : modèle de données, SQL, transactions, jeux de caractères, couche d’accès et processus d’exploitation. Qui considère la migration comme un simple export obtient généralement les mêmes problèmes qu’il cherchait à résoudre — simplement sur un nouveau serveur.

Une approche par étapes avec un import reproductible, un mapping de champs soigné, une validation précoce et un remplacement clair de BDE (par ex. via FireDAC) fournit en revanche une base stable : pour l’exploitation multi‑utilisateur, pour les intégrations, pour les services et pour les prochaines étapes de la modernisation Delphi.

Si vous souhaitez planifier votre migration de façon sûre sur le plan fonctionnel et la réaliser sans interruption opérationnelle, discutons volontiers de l’état initial, des risques et d’un plan d’étapes réaliste : https://net-base-software-gmbh.de/kontakt/