Dans de nombreuses entreprises, Borland Database Engine (BDE) fait encore partie aujourd’hui d’applications Delphi critiques pour l’activité : logique métier accumulée, accès aux données proches de l’interface utilisateur avec TTable/TQuery, parfois encore Paradox/dBase, parfois des installations client/serveur anciennes. Souvent la réalité est la suivante : le logiciel fonctionne, les utilisateurs connaissent les processus, et au quotidien il n’y a aucune raison immédiate de « toucher quoi que ce soit ». En même temps, le socle technique évolue : les systèmes d’exploitation sont renforcés, le déploiement est standardisé, le 64‑bits est attendu, et le stockage des données devrait se faire sur des serveurs de base de données avec un concept clair de droits et de sauvegarde.
C’est précisément à ce point que « remplacer Borland BDE par remplacement de la BDE avec connexion native » devient une tâche stratégique de modernisation. BDE-Ablosung mit nativer Anbindung est, dans les versions récentes de Delphi, l’accès aux données établi pour les bases de données modernes. Il offre un comportement cohérent, des pilotes robustes, la prise en charge d’Unicode, du monitoring/tracing et une architecture capable de servir aussi bien des clients de bureau que des services et des serveurs REST. La transition n’est toutefois que rarement un simple échange de composant 1:1 – surtout lorsque l’application existante a intégré au fil des années des comportements spécifiques à la BDE (hypothèses sur les transactions, formats de données, filtres/tri, Cached Updates, rapports tiers).
Ce billet se concentre sur la démarche pratique : comment remplacer la BDE par FireDAC sans mettre en danger la logique métier et sans imposer un relaunch type « big bang » ? Vous recevrez un modèle applicable, des visions techniques cibles et des indications sur des zones problématiques typiques en environnement industriel.
Pourquoi le remplacement de la BDE aujourd’hui dépasse la simple maintenance technique
Tant qu’une application BDE fonctionne, le remplacement ressemble à un simple « nettoyage de code ». En pratique, la pression provient cependant le plus souvent d’enjeux opérationnels et de risques.
Déploiement, baselines de sécurité et clients « no‑touch »
La BDE est historiquement conçue pour une configuration locale (BDE Administrator, définitions d’alias, NetDir, fichiers de configuration partagés). Dans des environnements modernes, des étapes manuelles et des paramètres machine‑wide sont difficiles à concilier avec la distribution logicielle, le renforcement et l’auditabilité. FireDAC permet des déploiements beaucoup plus contrôlables, car les paramètres de connexion et les réglages des pilotes peuvent être gérés au plus proche de l’application.
64‑bits, modernisation Windows et nouvelles cibles de plateforme
Dès lors qu’une application doit fonctionner en 64‑bits (besoin mémoire, écosystème pilotes/Office, nouveau matériel, stratégies Terminal Server), la BDE devient pratiquement un blocage. FireDAC prend en charge de manière cohérente 32/64‑bits et constitue ainsi un élément central de toute modernisation Delphi qui ne doit pas échouer pour des raisons d’accès aux données. Par ailleurs, des sujets comme Windows 11 ARM64 et des architectures hybrides client/service deviennent enfin planifiables de manière propre.
Stratégie de base de données : quitter le mode fichier pour aller vers le mode serveur
Beaucoup d’applications BDE traînent encore des héritages des époques Paradox/dBase. Ces bases de données fichiers sont plus vulnérables en multi‑utilisateurs, plus difficiles à sauvegarder administrativement et mal adaptées aux exigences actuelles (rôles/permissions, chiffrement, monitoring, haute disponibilité). FireDAC n’est certes pas « le nouveau pilote Paradox », mais il constitue l’accès moderne à SQL Server, PostgreSQL, MariaDB et Firebird. En pratique, le remplacement de la BDE est souvent le signal de départ pour professionnaliser le stockage des données et l’exploitation.
Maintenabilité et capacité de diagnostic en exploitation
Un coût sous‑estimé est la recherche d’erreurs : problèmes de verrouillage sporadiques, comportement de curseur incohérent, conversions de paramètres difficiles à retracer ou problèmes réseau/chemins. FireDAC offre, via le logging, le monitoring et un typage plus clair, de meilleurs points d’appui pour des analyses d’erreurs reproductibles. Pour les entreprises qui exploitent une application à long terme et souhaitent l’étendre ponctuellement, c’est un bénéfice direct.
BDE vs. FireDAC : différences qui comptent dans la migration
Sur le papier, les composants se mappent. En réalité, il s’agit de changements de comportement qui peuvent générer des effets de bord métier. Une brève orientation :
Mapping des composants (comme point de départ)
- TDatabase (BDE) → TFDConnection (FireDAC)
- TQuery (BDE) → TFDQuery
- TTable (BDE) → TFDTable (dans les modernisations souvent mieux : accès basé sur Query/View)
- TStoredProc (BDE) → TFDStoredProc
Les différences de comportement les plus fréquentes
- Paramètres et types de données : FireDAC travaille de manière plus précise. un SQL du type « ça ira » saute plus vite aux yeux (p. ex. valeurs de date comme chaînes, conversions implicites, nullabilité ambiguë).
- Transactions : Le code hérité contient souvent des hypothèses d’commit implicite (fermeture de Dataset, patterns proches d’AutoCommit, Cached Updates). Avec FireDAC, une gestion consciente des transactions est souhaitable car elle améliore la cohérence métier.
- Curseur/Fetch : FireDAC a d’autres valeurs par défaut et davantage de réglages. Des patterns inefficaces (gros jeux de résultats pour des listes UI) deviennent plus visibles mais peuvent être optimisés de manière ciblée.
- Unicode : Dans les versions modernes de Delphi, Unicode est la norme. La chaîne FireDAC (bibliothèque client, options de connexion, collation DB, types de champs) doit être cohérente, sinon des problèmes d’encodage et de comparaison peuvent survenir.
- Déploiement : Selon la base, des bibliothèques clientes sont nécessaires (p. ex. libpq pour PostgreSQL). Cela doit être planifié tôt, sinon des surprises proches de la production apparaissent.
Image cible pour une architecture FireDAC : stable, testable, extensible
Un remplacement de la BDE ne doit pas aboutir à du « FireDAC partout n’importe comment ». Une image cible durable est particulièrement précieuse si l’application doit être développée ultérieurement ou intégrée à des services/portails.
Objectif minimal : une couche de connexion uniforme
Plutôt que des connexions dispersées dans les formulaires, on recommande une couche de connexion centrale :
- Création et configuration de TFDConnection en un seul endroit
- Timeouts, encodage/jeu de caractères, gestion d’erreurs uniformes
- Basculer Dev/Test/Prod sans retouches manuelles
- Optionnel : activation centrale du tracing/monitoring pour les cas de diagnostic
Recommandé : délimiter clairement les transactions dans la logique métier
Beaucoup d’applications legacy répartissent les modifications de données sur des événements UI. Cela augmente le risque de mises à jour partielles et complique les tests. Une approche FireDAC stable est : le cas d’utilisation (service/logique métier) démarre et termine la transaction, pas l’UI. Même dans un logiciel VCL pur, cela crée un noyau robuste, plus facilement réutilisable ensuite comme service ou API.
Extensible vers des services et REST
Qui souhaite plus tard ajouter un serveur REST, exploiter des services Windows ou Linux, ou connecter un portail client, bénéficiera d’une couche de données propre. FireDAC est adapté si la gestion des connexions, le traitement des erreurs et – selon la charge serveur – le pooling sont au moins envisagés comme image cible. Cela n’a pas besoin d’être implémenté d’emblée, mais l’architecture ne doit pas le bloquer.
Stratégie de migration : introduire FireDAC progressivement, retirer la BDE de façon contrôlée
Dans les environnements B2B, un big bang est rarement réaliste : trop de processus métier, trop de responsabilités opérationnelles, peu d’acceptation pour de longues interruptions. Un remplacement progressif est généralement la voie sûre.
Phase 1 : inventaire et carte des risques
Un inventaire utile ne compte pas seulement les composants, il évalue les comportements et les couplages :
- Quelles bases sont utilisées : Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB ?
- Où sont les accès TTable, où le SQL est‑il utilisé via TQuery, où y a‑t‑il des procédures stockées ?
- Comment les transactions sont‑elles gérées aujourd’hui (explicites, implicites, Cached Updates, schémas mixtes) ?
- Quels rapports/exports attendent des propriétés particulières des datasets (tri, filtrage, champs calculés) ?
- Quelles composantes tierces ou frameworks internes sont spécifiques à la BDE ?
De cette cartographie découle si le remplacement concerne « seulement » l’accès ou si une refonte de la base (p. ex. Paradox → SQL Server/PostgreSQL/MariaDB) est souhaitable ou nécessaire.
Phase 2 : fondation FireDAC (sans refonte UI)
Avant de migrer les écrans, FireDAC doit être techniquement en place proprement :
- DataModule central ou classe service avec TFDConnection
- Modèle de configuration pour les chaînes de connexion (p. ex. INI/JSON) et gestion propre des secrets
- Gestion d’erreurs standardisée (transformer les exceptions DB en messages compréhensibles et loguables)
- Options de tracing/monitoring pour le pilote (activables pour un pilote), pas continuellement « bruyantes »
Il est important que cela aboutisse à des standards contraignants : conventions de nommage, règles de paramétrage, schéma de logging, réglages par défaut par base.
Phase 3 : module pilote avec réel enjeu métier
Un bon module pilote est fonctionnellement délimité mais réellement utilisé. Objectif : développer et vérifier des patterns.
- TQuery → TFDQuery (incl. paramétrage et typage)
- Définir le cadre transactionnel et le rendre visible dans le code
- Prouver l’égalité des résultats (comparer les jeux de résultats pertinents métier)
- Mesurer la performance (temps de réponse, charge DB, trafic réseau)
À la fin du pilote, une checklist interne doit exister et servir à migrer chaque module suivant. Cela réduit les risques et rend les efforts plus planifiables.
Phase 4 : migration à grande échelle et nettoyage du déploiement
Après le pilote, la migration se fait module par module. Parallèlement, la BDE est progressivement retirée des dépendances opérationnelles :
- Supprimer les scripts d’installation et la documentation des configurations BDE
- Éliminer les définitions d’alias, la configuration NetDir et les chemins spéciaux
- Adapter les pipelines de build/release aux nouvelles dépendances (libs clientes, pilotes)
Ce nettoyage final est essentiel : tant que des éléments BDE survivent dans le déploiement, le risque opérationnel persiste.
Pièges : causes fréquentes d’effets de bord métier
Beaucoup de migrations échouent non pas à cause de FireDAC, mais à cause d’hypothèses implicites dans le code ancien. Ces domaines doivent être priorisés tôt.
Dialectes SQL et SQL historiquement évolué
Les applications BDE contiennent souvent du SQL qui fonctionnait « par hasard » avec un pilote particulier : JOIN implicites, utilisation incohérente des alias, fonctions spécifiques à une BD, tris non déterministes. En migration :
- Rendre le SQL explicite (syntaxe JOIN au lieu de jointures implicites via WHERE)
- Vérifier les mots réservés et les identifiants (p. ex. DATE, USER, ORDER comme noms de champs)
- Uniformiser ou encapsuler les fonctions de date/heure et de chaîne
FireDAC offre des possibilités d’adaptation, mais la solution durable est un SQL conforme à la BD et lisible.
Mappage des types : Boolean, Date/Heure, Memo/Blob, NULL
La BDE interprétait beaucoup de choses en pratique. FireDAC est plus strict – ce qui est bon, mais impose des règles. Sujets typiques :
- Boolean : BIT/SMALLINT/CHAR(1) – définir clairement au plan métier, éviter les conversions implicites
- Date/Heure : DATETIME vs. DATETIME2, millisecondes, logique de tri/comparaison ; questions de fuseau horaire dans les systèmes distribués
- Memo/Blob : comportement de récupération (OnDemand), encodage, consommation mémoire côté client
- Nullabilité : Le code ancien qui mélange chaînes vides et NULL mène à des erreurs logiques difficiles à repérer
Une pratique éprouvée est un catalogue de types léger : pour chaque table/colonne métier importante, définir les types cibles (BD et Delphi) ainsi que des règles pour NULL, valeurs par défaut et formats.
Transactions : d’implicite à orchestré consciemment
Dans les projets Delphi hérités, une erreur fréquente est que le système s’est appuyé sur des commits implicites (« si je ferme le Dataset, c’est enregistré »). FireDAC fournit des API claires (StartTransaction, Commit, Rollback). Le bénéfice de la modernisation naît quand les transactions sont comprises comme un cadre métier :
- Le cas d’utilisation démarre la transaction
- Plusieurs mises à jour s’exécutent au sein de la même Connection
- Commit/Rollback se font de manière centrale avec un traitement d’erreur traçable
Cela réduit les incohérences et est décisif si l’application doit ensuite être complétée par des services ou des interfaces.
Cached Updates et gestion des conflits (concurrency)
Beaucoup d’applications BDE utilisaient Cached Updates comme mécanisme d’« édition hors ligne ». FireDAC peut proposer des fonctionnalités similaires, mais les règles doivent être explicites :
- Quels champs sont des clés, lesquels servent à la vérification de concurrence ?
- Comment les conflits sont‑ils résolus (RowVersion/Timestamp, « last write wins », décision par l’utilisateur) ?
- Que se passe‑t‑il en cas d’erreurs partielles dans des opérations par lot ?
Dans les modernisations, il est souvent judicieux de rapprocher la logique de résolution des conflits de la logique métier ou de la placer dans une couche service, plutôt que de la laisser uniquement dans le comportement des datasets UI.
Applications fortement TTable/Paradox : FireDAC n’est pas la seule question
Si l’application repose fortement sur un accès basé fichier (TTable sur Paradox), « remplacer la BDE par FireDAC » n’est qu’une partie de la vérité. FireDAC est avant tout destiné aux bases SQL. La décision centrale est alors : modernise‑t‑on le stockage vers une base serveur ?
- Migration vers SQL Server, PostgreSQL ou MariaDB
- Introduction d’un concept rôles/permissions et de processus clairs de backup/restore
- Exploitation multi‑utilisateur stable sans problèmes de verrouillage fichier
Si un changement immédiat de base de données n’est pas possible organisationnellement, une approche en deux étapes est souvent pragmatique : d’abord stabiliser la couche d’accès et réduire le couplage UI, puis réaliser la migration des données avec une stratégie claire de test et de bascule.
Reporting, exports et composants tiers
Les rapports dépendent souvent de détails : ordres de tri, enchaînements de filtres, champs calculés, comportement maître/détail. Pour une mise en place contrôlée :
- Identifier les rapports critiques et les traiter comme une suite de tests de régression
- Générer les jeux de données pour les rapports de façon déterministe (vues/procédures stockées ou requêtes clairement définies)
- Réduire les chaînes de filtres côté UI qui dépendent du comportement du dataset
L’objectif est l’égalité reproductible des résultats, en particulier pour les rapports soumis à audit.
Mise à niveau architecturale lors de la migration FireDAC : découpler de manière pragmatique
Le remplacement de la BDE est un bon moment pour extraire l’accès aux données des formulaires et des gestionnaires d’événements. Cela n’implique pas nécessairement un projet de réarchitecture complet. Des mesures modérées apportent souvent un fort impact.
Structure cible pragmatique (compatible avec une architecture en 3 couches)
- Connection/Unit‑of‑Work : gère la connexion et la transaction, fournit des objets Query
- Repository/DAO : encapsule le SQL et l’accès aux données par domaine métier
- Service/Cas d’utilisation : orchestre la logique métier, les validations et le cadre transactionnel
Cette structure est compatible avec une future architecture Layer‑3 et facilite les projets ultérieurs : interfaces REST, services en arrière‑plan, clients multiplateformes ou couplage à des portails.
Effet important : moins d’effets de bord globaux
Beaucoup de projets BDE travaillent avec des data modules globaux et des états implicites. FireDAC fonctionne aussi dans ce modèle, mais la modernisation est plus stable si les états sont localisés : cycle de vie clair de la Connection/Transaction, chemins d’erreur reproductibles, moins d’« effets secondaires » causés par un état global.
Performance et stabilité : configurer FireDAC de manière ciblée
FireDAC est performant, mais la performance résulte d’un ensemble : SQL, indexation, stratégie de fetch et gestion des connexions. Lors des migrations, il apparaît souvent que la BDE masquait des patterns inefficaces, parce que les volumes de données étaient plus faibles auparavant ou parce que le système s’exécutait localement.
Stratégies de fetch et listes UI
- Charger les listes avec uniquement les colonnes nécessaires (ne pas faire de SELECT *)
- Tri côté serveur et filtres ciblés plutôt que chaînes côté client
- Pour de grands volumes : pagination ou chargement incrémental
- Charger les champs LOB (Memo/Blob) uniquement quand c’est réellement nécessaire
FireDAC propose des options adaptées ; l’essentiel est la décision métier sur les données dont un utilisateur a réellement besoin dans chaque contexte.
Prepared Statements et paramétrisation
Les requêtes paramétrées sont non seulement un standard de sécurité (éviter l’injection SQL), mais améliorent dans de nombreuses bases la réutilisation des plans d’exécution. De plus, l’imprécision des types dans le code ancien devient visible et peut être corrigée. Dans les systèmes hérités, c’est un gain de qualité qui réduit les cas particuliers et améliore le diagnostic.
Gestion des connexions : Desktop vs Service/REST
Dans les clients desktop classiques, une connexion longue par client est souvent praticable. Dans les services ou serveurs REST, les patterns diffèrent : requêtes courtes, accès parallèles, pooling de connexions. Qui considère le remplacement de la BDE comme partie d’une modernisation plus large doit intégrer ces différences dans l’image cible, afin que les évolutions ultérieures ne repartent pas de zéro côté accès aux données.
Stratégie de test et d’acceptation : prouver l’égalité des résultats
Le principal risque lors d’une BDE‑Ablösung n’est pas souvent que « l’application ne démarre pas », mais des écarts métier discrets : tris, arrondis, gestion des NULL, frontières de transaction, effets secondaires de triggers/contraintes dans des bases modernes. Une stratégie de test solide comprend :
- Régression SQL : exécuter les requêtes critiques sur des jeux de test définis et comparer les jeux de résultats
- Tests de cas d’utilisation : vérifier les processus cœur (p. ex. comptabilisation, validation, annulation, import/export) avec des valeurs attendues
- Tests multi‑utilisateurs/stabilité : comportement de verrouillage, deadlocks, timeouts, durée des transactions
- Logging/observabilité : recueillir les erreurs DB de manière structurée (codes d’erreur, contexte, requête en cause), et pas seulement afficher un « dialogue d’erreur »
Les entreprises tirent un double bénéfice : les tests sécurisent la migration et créent une base pour déployer ultérieurement des modifications du modèle de données ou des interfaces de manière contrôlée.
Bases cibles dans les projets FireDAC : options typiques
FireDAC est volontairement large, mais chaque base impose ses règles. Dans les modernisations, les cibles suivantes sont fréquentes :
SQL Server
Typique dans des environnements IT dominés par Windows. Points importants : types Unicode cohérents (NVARCHAR), types temporels modernes (DATETIME2), stratégie claire d’Identity/Sequence, niveaux d’isolation définis et gestion propre des verrous.
PostgreSQL
Fort sur l’intégrité et les fonctionnalités. En migration, attention à : sensibilité à la casse des identifiants, types (boolean/uuid/jsonb) et différences de dialecte. FireDAC peut connecter PostgreSQL en production si les bibliothèques clientes et le déploiement sont bien organisés.
MariaDB/MySQL
Souvent choisi quand une partie web/portail doit s’articuler avec le logiciel desktop. Important : utf8mb4 de façon cohérente, InnoDB comme moteur, stratégie d’indexation et de transactions claire. FireDAC supporte MariaDB/MySQL de façon fiable si les paramètres et types sont définis.
Indépendamment de la cible, un remplacement de la BDE est le plus stable lorsqu’il est accompagné de normes de base de données (versioning du schéma, scripts de migration, rôles/permissions, backup/restore, monitoring).
Recommandations pratiques pour une migration FireDAC planifiable
Réduire les dépendances avant d’échanger massivement de composants
Si le SQL et la logique des datasets sont imbriqués dans de nombreux formulaires, chaque changement devient coûteux. Une étape intermédiaire qui regroupe le SQL dans quelques classes d’accès réduit fortement la surface de migration. Ensuite, la bascule effective vers FireDAC est souvent plus rapide et moins risquée.
Migrer tôt un processus transactionnel central
Les « listes simples » sont des débuts confortables, mais il est moins risqué de migrer tôt un processus avec de véritables mises à jour et dépendances. Quand les transactions, types et chemins d’erreur y sont propres, le reste de la migration devient plus planifiable.
Traiter le déploiement comme un travail de premier plan
La modification du code n’est que la moitié du chemin. Clarifiez tôt :
- Quelles bibliothèques clientes/pilotes sont nécessaires par base ?
- Comment seront‑ils versionnés, signés (si pertinent) et déployés ?
- Comment sont gérés les paramètres de connexion, et qui est autorisé à les modifier ?
- Quel est le processus de support si les accès DB échouent ?
Utiliser FireDAC comme ancre de modernisation – sans refaire tout de zéro
Le remplacement est une opportunité pour pointer des leviers qualité ciblés : paramétrisation, frontières transactionnelles, logging, textes d’erreur uniformes. Cela réduit les coûts d’exploitation et rend les extensions ultérieures (interfaces, services) nettement moins risquées, sans réinventer fonctionnellement l’application.
Conclusion : remplacer la BDE par FireDAC est une modernisation maîtrisable – si elle est traitée comme un sujet d’architecture
La BDE a supporté de nombreuses applications Delphi pendant des années. Aujourd’hui cependant, elle représente un risque structurel : pour le 64‑bits, pour un déploiement standardisé, pour les exigences de sécurité modernes et pour la connexion aux bases contemporaines. FireDAC est l’héritier approprié, mais pas comme un « échange de composant du jour au lendemain ». La voie sûre est une migration progressive avec une fondation propre, un module pilote, des règles contraignantes pour les types et les transactions ainsi que des tests qui prouvent l’égalité des résultats.
Si vous souhaitez planifier de manière structurée la suppression de la BDE – y compris l’analyse de l’existant, le chemin de migration et l’architecture cible FireDAC – un bilan technique de vos conditions cadres est l’étape la plus raisonnable : https://net-base-software-gmbh.de/kontakt/