Remplacer Borland BDE par FireDAC : Guide pour une modernisation Delphi sécurisée sans Big Bang

Dans de nombreuses entreprises, la Borland Database Engine (BDE) fait encore aujourd’hui partie d’applications Delphi critiques pour l’activité : logique métier accumulée, accès aux données proches de l’IU via TTable/TQuery, parfois encore Paradox/dBase, parfois des premières installations client/serveur. Souvent, la réalité est la suivante : le logiciel fonctionne, les utilisateurs connaissent les processus, et dans le quotidien il n’y a pas de raison immédiate de « toucher » quoi que ce soit. Parallèlement, le socle technique évolue : les systèmes d’exploitation sont durcis, le déploiement est standardisé, le 64 bits est attendu, et la gestion des données doit se faire sur des serveurs de bases de données avec un concept clair de droits et de sauvegarde.

C’est précisément à ce point que « remplacer Borland BDE par une migration BDE-Ablösung avec un accès natif » devient une tâche stratégique de modernisation. BDE-Ablosung mit nativer Anbindung est, dans les versions actuelles de Delphi, l’accès aux données établi pour les bases modernes. Il fournit un comportement cohérent, des pilotes robustes, la prise en charge de l’Unicode, le monitoring/tracing et une architecture qui peut servir aussi bien des clients de bureau que des services et des REST-serveurs. Le passage n’est toutefois que rarement un simple échange 1:1 de composants — en particulier lorsque l’application existante a « intégré » pendant des années des comportements spécifiques à BDE (hypothèses de transaction, formats de données, filtres/tri, Cached Updates, rapports tiers).

Ce billet se concentre sur l’approche pratique : comment remplacer BDE par FireDAC sans mettre en danger la logique métier et sans imposer un lancement « big-bang » ? Vous obtenez un modèle exécutable, des cibles techniques et des indications sur les zones à risque typiques en exploitation.

Pourquoi la migration BDE est aujourd’hui plus que de la maintenance technique

Tant qu’une application BDE fonctionne, une migration ressemble à un simple « nettoyage de code ». Dans la pratique, la pression vient toutefois le plus souvent d’enjeux d’exploitation et de risque.

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, les étapes manuelles et les paramètres globaux sont difficiles à concilier avec la distribution logicielle, le durcissement et l’auditabilité. FireDAC permet des déploiements nettement plus contrôlables, car les paramètres de connexion et les options de pilote peuvent être gérés au plus près de l’application.

64‑bit, modernisation Windows et nouvelles cibles de plateforme

Dès lors qu’une application doit fonctionner en 64‑bits (besoins mémoire, écosystème pilotes/bureautique, nouveau matériel, stratégies Terminal Server), la BDE devient de fait un blocage. FireDAC prend en charge 32/64‑bits de façon cohérente et constitue un élément central de toute modernisation Delphi qui ne doit pas échouer au niveau de l’accès aux données. Par ailleurs, des sujets comme Windows 11 ARM64 et les architectures client/service hybrides deviennent planifiables de manière sérieuse.

Stratégie de base de données : sortir du fichier pour aller vers le serveur

Beaucoup d’applications BDE portent encore des héritages des époques Paradox/dBase. Ces bases de fichiers sont plus fragiles en exploitation multi‑utilisateur, plus difficiles à sauvegarder administrativement et mal adaptées aux exigences actuelles (rôles/permissions, chiffrement, monitoring, haute disponibilité). FireDAC n’est pas « le nouveau pilote Paradox », mais l’accès moderne à SQL Server, PostgreSQL, MariaDB et Firebird. Dans la pratique, la migration BDE est souvent le signal de départ pour professionnaliser la gestion et l’exploitation des données.

Maintenabilité et capacité de diagnostic en exploitation

Un facteur de coût sous‑estimé est la recherche d’erreurs : problèmes de verrouillage sporadiques, comportement de curseur incohérent, conversions de paramètres difficiles à suivre ou problématiques réseau/chemins. FireDAC offre, avec le logging, le monitoring et un typage plus clair, de meilleurs leviers pour des diagnostics reproductibles. Pour les entreprises qui exploitent une application sur le long terme et l’étendent ponctuellement, c’est un bénéfice immédiat.

BDE vs. FireDAC : différences qui comptent pour la migration

Sur le papier, les composants se correspondent. En réalité, il s’agit de changements de comportement qui peuvent produire des effets secondaires métiers. Une rapide orientation :

Mapping des composants (point de départ)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (dans les modernisations, souvent préférable : 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 est plus précis. le SQL « ça passera » devient plus rapidement visible (par ex. dates en chaînes, conversions implicites, nullability ambiguë).
• Transactions : le code legacy contient souvent des hypothèses d’commit implicites (fermeture de Dataset, schémas de type AutoCommit, Cached Updates). Avec FireDAC, il est utile de commander explicitement les transactions, car cela améliore la cohérence métier.
• Curseur/Fetch : FireDAC a d’autres valeurs par défaut et davantage de réglages. Les schémas inefficaces (grands jeux de résultats pour des listes UI) deviennent visibles mais peuvent être optimisés de manière ciblée.
• Unicode : Dans les versions modernes de Delphi, l’Unicode est la norme. La chaîne FireDAC (bibliothèque cliente, options de connexion, collation DB, types de champs) doit être cohérente, sinon des problèmes d’encodage et de comparaison apparaîtront.
• Déploiement : selon la base, des bibliothèques clientes sont nécessaires (par ex. libpq pour PostgreSQL). Cela doit être planifié tôt, sinon des surprises près de la production surviennent.

Vision cible pour une architecture FireDAC : stable, testable, extensible

Une migration BDE ne doit pas déboucher sur un « FireDAC partout n’importe comment ». Une vision cible solide est particulièrement utile si l’application doit être maintenue ou intégrée dans des services/portails.

Objectif minimal : couche de connexion unifiée

Plutôt que des connexions disséminées dans les formulaires, on recommande une couche centrale de connexion :

• Création et configuration de TFDConnection en un point
• Timeouts, encodage/jeu de caractères, gestion d’erreurs uniformes
• Basculement Dev/Test/Prod sans intervention manuelle
• Optionnel : activation centralisée du tracing/monitoring pour diagnostics

Recommandé : frontières de transaction claires dans la logique métier

Beaucoup d’anciennes applications 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 consiste à ce que le cas d’utilisation (service/logiciel métier) démarre et termine la transaction, pas l’IU. Même pour un logiciel VCL de bureau pur, cela crée un noyau robuste, plus facilement réutilisable ensuite comme service ou API.

Extensible vers des services et REST

Si l’on prévoit d’ajouter ultérieurement un REST-serveur, d’exploiter des services Windows ou Linux-services ou d’interfacer un portail client, un layer de données propre est bénéfique. FireDAC s’y prête dès lors que la gestion des connexions, le traitement d’erreurs et — selon la charge serveur — le pooling sont envisagés comme objectifs. Cela n’a pas besoin d’être réalisé dans la première étape, mais l’architecture ne doit pas le bloquer.

Stratégie de migration : introduire FireDAC pas à pas et retirer BDE de manière contrôlée

En B2B, un « big bang » est rarement réaliste : trop de processus métier, trop de responsabilités d’exploitation, trop peu d’acceptation pour de longues indisponibilités. Une migration progressive de BDE est généralement la voie sûre.

Phase 1 : inventaire et carte des risques

Un inventaire utile ne recense pas seulement des composants, il évalue comportements et couplages :

• Quelles bases sont utilisées : Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB ?
• Où se trouvent les accès TTable, où SQL via TQuery, où les 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 précises des datasets (tri, filtres, champs calculés) ?
• Quelles composantes tierces ou frameworks internes sont spécifiques à BDE ?

De cette carte découlera si la migration concerne « seulement » l’accès ou si, en parallèle, une refonte de la base de données (par ex. Paradox → SQL Server/PostgreSQL/MariaDB) est judicieuse ou nécessaire.

Phase 2 : fondation FireDAC (sans refonte UI)

Avant de migrer les écrans, FireDAC doit être en place techniquement :

• DataModule central ou classe de service avec TFDConnection
• Modèle de configuration pour les chaînes de connexion (ex. INI/JSON) et gestion propre des secrets
• Gestion d’erreurs standardisée (transformer les DB‑Exceptions en messages compréhensibles et loguables)
• Options de tracing/monitoring pour exploitation pilote (activables de façon ciblée, pas en mode « bruyant » permanent)

Il est important d’en tirer des standards contraignants : conventions de nommage, règles pour les paramètres, schéma de logging, paramètres par défaut par base.

Phase 3 : module pilote avec réelle valeur métier

Un bon 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
• Vérifier l’égalité des résultats (comparer les jeux de résultats d’importance métier)
• Mesurer la performance (temps de réponse, charge DB, trafic réseau)

À l’issue du pilote, une checklist interne devrait exister, selon laquelle chaque module suivant est migré. Cela réduit le risque et rend l’effort plus prévisible.

Phase 4 : migration à grande échelle et nettoyage du déploiement

Après le pilote, la migration s’opère module par module. En parallèle, la dépendance à BDE est retirée :

• Retirer les scripts d’installation et la documentation des setups BDE
• Éliminer les définitions d’alias, la configuration NetDir et les chemins spéciaux
• Aligner la pipeline de build/release sur les nouvelles dépendances (libs clientes, pilotes)

Ce retrait est crucial : tant que des éléments BDE subsistent dans le déploiement, le risque opérationnel demeure.

Pièges : causes fréquentes d’effets secondaires métiers

Nombre de migrations échouent non pas à cause de FireDAC, mais à cause d’hypothèses implicites dans le code legacy. Ces domaines doivent être priorisés tôt.

Dialects SQL et SQL hérité

Les applications BDE contiennent souvent du SQL qui fonctionnait « par hasard » avec un pilote particulier : jointures implicites, usage incohérent des alias, fonctions spécifiques au SGBD, tris ambigus. En migration :

• Rendre le SQL explicite (syntax JOIN au lieu de joints implicites via WHERE)
• Vérifier les mots réservés et les identifiants (ex. DATE, USER, ORDER comme noms de champ)
• Unifier ou encapsuler les fonctions date/heure et de chaîne

FireDAC offre des options d’adaptation, mais la solution pérenne est un SQL conforme à la base et lisible.

Mapping des types : Boolean, Date/Time, Memo/Blob, NULL

La BDE a souvent interprété beaucoup de choses. FireDAC est plus strict — ce qui est positif mais exige des règles. Thèmes typiques :

• Boolean : BIT/SMALLINT/CHAR(1) — définir clairement sur le plan métier, éviter les conversions implicites
• Date/Heure : DATETIME vs. DATETIME2, millisecondes, logique de tri/comparaison ; questions de fuseau horaire pour les systèmes distribués
• Memo/Blob : comportement de fetch (OnDemand), encodage, consommation mémoire côté client
• NULLability : le code ancien qui mélange chaînes vides et NULL conduit à des erreurs logiques difficiles à détecter

Une pratique éprouvée est un catalogue de types succinct : pour chaque table/colonne importante, définir les types cibles (DB et Delphi) plus des règles pour NULL, valeurs par défaut et formats.

Transactions : d’implicite à orchestré consciemment

Dans les projets Delphi legacy, une erreur fréquente est que le système compte sur des commits implicites (« si je ferme le Dataset, c’est sauvegardé »). FireDAC propose des API claires (StartTransaction, Commit, Rollback). Le gain de modernisation survient lorsque les transactions sont comprises comme un cadre métier :

• Le use case démarre la transaction
• Plusieurs mises à jour s’exécutent dans la même Connection
• Commit/Rollback sont effectués de manière centrale avec un traitement d’erreur traçable

Cela réduit les incohérences et est essentiel si l’application est ensuite complétée par des services ou des interfaces.

Cached Updates et gestion des conflits (concurrency)

Beaucoup d’applications BDE utilisent les Cached Updates comme mécanisme d’« édition hors ligne ». FireDAC peut offrir des fonctionnalités similaires, mais les règles doivent être explicites :

• Quels champs sont clés, lesquels servent à la vérification de concurrence ?
• Comment les conflits sont‑ils résolus (RowVersion/Timestamp, « last write wins », choix utilisateur) ?
• Que se passe‑t‑il en cas d’erreurs partielles dans des opérations batch ?

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 de service, plutôt que de la cacher exclusivement dans le comportement des datasets UI.

Applications centrées sur TTable/Paradox : FireDAC n’est pas la seule problématique

Si l’application repose fortement sur un accès fichier (TTable vers Paradox), « remplacer BDE par FireDAC » n’est qu’une partie de la vérité. FireDAC est principalement destiné aux bases SQL. La décision centrale est alors : modernise‑t‑on la persistance vers une base serveur ?

• Migration vers SQL Server, PostgreSQL ou MariaDB
• Introduction d’un concept rôles/permissions et de processus de sauvegarde/restauration clairs
• Exploitation multi‑utilisateur stable sans problèmes de verrouillage de fichiers

Si un basculement immédiat de la base est impossible pour des raisons organisationnelles, une approche en deux étapes est souvent pragmatique : stabiliser d’abord la couche d’accès et réduire le couplage UI, puis réaliser la migration des données avec une stratégie de test et de cutover bien définie.

Reporting, exports et composants tiers

Les rapports dépendent souvent de détails : tris, ordre des filtres, champs calculés, comportement master/detail. Pour une transition contrôlée :

• Identifier les rapports critiques et les traiter comme une suite de tests de régression
• Générer des jeux de données pour les rapports de manière 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 des analyses soumises à audit.

Mise à niveau architecturale lors de la migration FireDAC : découpler de manière pragmatique

La migration BDE est une bonne occasion d’extraire l’accès aux données des formulaires et des gestionnaires d’événements. Cela ne signifie pas qu’un projet complet de réarchitecture soit nécessaire. Des mesures modestes produisent souvent un fort effet.

Structure cible pragmatique (compatible avec une architecture Layer-3)

• Connection/Unit-of-Work : gère Connection et transaction, fournit des objets Query
• Repository/DAO : encapsule le SQL et l’accès aux données par domaine métier
• Service/Use Case : orchestre la logique métier, les validations et le cadre transactionnel

Cette structure est compatible avec une future Layer-3 Architektur et facilite les projets suivants : interfaces REST, services d’arrière‑plan, clients multiplateformes ou couplage à des portails.

Effet important : moins d’effets secondaires globaux

Beaucoup de projets BDE utilisent des data modules globaux et des états implicites. FireDAC peut fonctionner ainsi aussi, mais la modernisation est plus stable lorsque les états sont localisés : cycle de vie clair de la Connection/Transaction, chemins d’erreur reproductibles, moins d’« effets de bord » dus à l’état global.

Performance et stabilité : configurer FireDAC de façon ciblée

FireDAC est performant, mais la performance résulte d’une combinaison SQL, indexation, stratégie de fetch et gestion des connexions. Dans les migrations, on constate souvent que BDE masquait des schémas inefficaces parce que les volumes de données étaient plus faibles auparavant ou parce que le système tournait localement.

Stratégies de fetch et listes UI

• Charger seulement les colonnes nécessaires pour les listes (pas de SELECT *)
• Tri côté serveur et filtres ciblés plutôt que des chaînes côté client
• Pour de grands volumes : pagination ou chargement incrémental
• Charger les champs LOB (Memo/Blob) uniquement si nécessaire

FireDAC propose des options adaptées ; l’essentiel est la décision métier sur les données réellement nécessaires à l’utilisateur dans chaque contexte.

Prepared Statements et paramétrisation

Les requêtes paramétrées ne sont pas uniquement une norme de sécurité (prévention des injections SQL), elles améliorent aussi la réutilisation des plans de requête dans de nombreuses bases. Elles rendent aussi visibles les incorrections de typage dans le code ancien et permettent des corrections ciblées. Dans des systèmes accumulé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 des clients classiques de bureau, une connection longue par client est souvent acceptable. Dans des services ou des serveurs REST, d’autres modèles s’imposent : requêtes courtes, accès parallèles, pool de connexions. Si la migration BDE s’inscrit dans une modernisation plus large, ces différences doivent être prises en compte dans la vision cible afin que les extensions ultérieures ne recommencent pas depuis le début au niveau de l’accès aux données.

Stratégie de test et d’acceptation : prouver l’égalité des résultats

Le principal risque lors de la migration BDE n’est pas que « l’application ne démarre pas », mais des divergences métiers discrètes : tris, arrondis, gestion des NULL, limites transactionnelles, effets secondaires de trigger/contraintes dans des BD 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 clés (par ex. comptabilisation, validation, annulation, import/export) avec des valeurs attendues
• Tests multi‑utilisateurs/stabilité : comportement de verrouillage, deadlocks, timeouts, durée des transactions
• Logging/Observability : capturer les erreurs BD de façon structurée (codes d’erreur, contexte, requête concernée), pas seulement des boîtes d’erreur

Les entreprises en retirent un double bénéfice : ces tests sécurisent la migration et constituent 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 a ses règles. Dans les modernisations, les cibles suivantes sont fréquentes :

SQL Server

Typique dans des paysages 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 nette des verrous.

PostgreSQL

Fort sur l’intégrité et les fonctionnalités. En migration : 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 organisés proprement.

MariaDB/MySQL

Souvent choisi quand le logiciel de bureau s’articule avec des composants web/portail. Important : utf8mb4 systématique, InnoDB comme moteur, stratégie d’indexation et de transaction propre. FireDAC prend en charge MariaDB/MySQL de façon fiable si paramètres et types sont clairement définis.

Indépendamment de la cible, une migration BDE est la plus stable lorsque parallèlement émergent des standards de base de données (versionnement de schéma, scripts de migration, rôles/permissions, sauvegarde/restauration, monitoring).

Recommandations pratiques pour une migration FireDAC planifiable

Réduire les dépendances avant de remplacer massivement des composants

Si le SQL et la logique de dataset sont répandus dans de nombreux formulaires, chaque changement coûte cher. Une étape intermédiaire qui concentre le SQL dans quelques classes d’accès réduit fortement la surface de migration. Ensuite, la bascule vers FireDAC est souvent plus rapide et moins risquée.

Migrer tôt un processus transactionnel central

Les « listes simples » sont faciles comme point d’entrée, mais réduire les risques implique de migrer tôt un processus avec de véritables mises à jour et dépendances. Si transactions, types de données et chemins d’erreur y sont propres, le reste de la migration devient plus prévisible.

Traiter le déploiement comme un travail de premier plan

La modification du code n’est qu’une moitié du travail. Clarifiez tôt :

• Quelles bibliothèques clientes/pilotes sont nécessaires par base ?
• Comment sont‑ils versionnés, signés (le cas échéant) et déployés ?
• Comment les paramètres de connexion sont‑ils gérés, et qui peut les modifier ?
• Quel est le processus de support lorsque les accès BD échouent ?

Utiliser FireDAC comme levier de modernisation — sans repartir à zéro

La migration est une opportunité pour des leviers qualité ciblés : paramétrisation, frontières de transactions, logging, messages 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 la logique métier de l’application.

Conclusion : la migration BDE vers FireDAC est une modernisation contrôlable — si elle est traitée comme un thème d’architecture

La BDE a porté de nombreuses applications Delphi pendant des années. Aujourd’hui, elle constitue néanmoins un risque structurel : pour le 64‑bits, pour un déploiement standardisé, pour les exigences de sécurité modernes et pour l’interfaçage avec des bases de données actuelles. 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 foundation propre, un module pilote, des règles contraignantes pour types et transactions et des tests démontrant l’égalité des résultats.

Si vous souhaitez planifier de manière structurée la migration BDE — y compris l’analyse d’existant, le chemin de migration et l’architecture cible FireDAC — une évaluation technique de vos contraintes est l’étape suivante la plus pertinente : https://net-base-software-gmbh.de/kontakt/