Substituir Borland BDE per FireDAC: Guia per a una modernització segura de Delphi sense Big Bang

En moltes empreses la Borland Database Engine (BDE) encara forma part d’aplicacions crucials per al negoci Delphi: lògica de negoci desenvolupada al llarg del temps, accessos a dades pròxims a la UI amb TTable/TQuery, en part encara Paradox/dBase i en part instal·lacions Client/Server primerenques. Sovint la realitat és: el programari funciona, els usuaris coneixen els processos i en el dia a dia no hi ha motiu immediat per “tocar res”. Al mateix temps el substrat tècnic està canviant: els sistemes operatius s’endureixen, el desplegament es normalitza, s’espera 64‑bit i la persistència de dades ha de migrar a servidors de base de dades amb un concepte net de drets i còpies de seguretat.

Precisament aquí «substituir Borland BDE per BDE-reemplaçament amb integració nativa» esdevé una tasca estratègica de modernització. BDE-Ablosung mit nativer Anbindung és en les versions actuals de Delphi l’accés a dades establert per a bases de dades modernes. Proporciona comportament consistent, drivers robustos, suport Unicode, monitoring/tracing i una arquitectura que pot donar servei tant a clients d’escriptori com a serveis i a servidors REST. El canvi rarament és només una substitució 1:1 de components, sobretot quan l’aplicació existent ha incorporat durant anys comportaments específics de BDE (supòsits sobre transaccions, formats de dades, filtres/ordenacions, Cached Updates, informes de tercers).

Aquest article se centra en l’enfocament pràctic: com substituir BDE per FireDAC sense posar en risc la lògica de negoci i sense forçar un relançament tipus Big‑Bang? Rebrà un model aplicable, imatges tècniques objectives i indicacions sobre zones problemàtiques típiques en l’operació empresarial.

Per què el reemplaçament de BDE avui és més que manteniment tècnic

Mentre una aplicació basada en BDE funcioni, una substitució pot semblar un simple „netejar codi“. A la pràctica, la pressió prové sovint de temes d’operació i risc.

Desplegament, security‑baselines i clients „No‑Touch“

La BDE està històricament pensada per a configuracions locals (BDE Administrator, definicions d’Aliases, NetDir, fitxers de configuració compartits). En entorns moderns, passos manuals i ajustos a nivell de màquina encaixen malament amb la distribució de software, l’enduriment i l’auditoria. FireDAC permet desplegaments significativament més controlables, perquè els paràmetres de connexió i les opcions del driver es poden gestionar a prop de l’aplicació.

64‑Bit, Windows‑modernització i nous objectius de plataforma

Abans no es pot esquivar la qüestió: quan una aplicació ha de funcionar en 64‑bit (necessitats de memòria, ecosistema de drivers/Office, maquinari nou, estratègies de Terminal Server), la BDE es converteix en blocador. FireDAC dóna suport de manera consistent a 32/64‑bit i, per tant, és un component central de qualsevol modernització Delphi que no ha de fallar pel costat de l’accés a dades. A més, temes com Windows 11 ARM64 i arquitectures híbrides client/servei es poden planificar amb garanties.

Estratègia de base de dades: sortir de l’accés basat en fitxers cap a servidors

Moltes aplicacions BDE arrosseguen llegats de l’època Paradox/dBase. Aquestes bases de dades de fitxers són més fràgils en entorns multiusuari, més costoses d’administrar i no s’ajusten bé als requisits actuals (rols/drets, xifrat, monitoring, alta disponibilitat). FireDAC no és simplement „el nou driver Paradox“, sinó l’accés modern a SQL Server, PostgreSQL, MariaDB i Firebird. A la pràctica, la substitució de BDE sovint és el senyal d’inici per professionalitzar la persistència i l’operació de dades.

Mantenibilitat i capacitat de diagnosi en producció

Un factor de cost subestimat és la recerca d’errors: problemes d’esperes intermitents, comportament inconsistent de cursor, conversions de paràmetres difícils de seguir o qüestions de xarxa/polsos. FireDAC aporta logging, monitoring i un comportament de tipus més clar, que ofereix punts d’atac millors per a anàlisis d’errors reproductibles. Per empreses que volen operar una aplicació a llarg termini i expandir‑la de manera puntual, aquest és un benefici directe.

BDE vs. FireDAC: diferències que compten en la migració

En el paper es poden mapar components. En la realitat es tracta de canvis de comportament que poden tenir efectes secundaris en la lògica de negoci. Una orientació breu:

Mapping de components (com a punt de partida)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (en modernitzacions sovint millor: accés basat en Query/View)
• TStoredProc (BDE) → TFDStoredProc

Les diferències de comportament més comuns

• Paràmetres i tipus de dades: FireDAC treballa amb més precisió. SQL de „ja anirà“ queda al descobert més ràpidament (per exemple valors de data com a strings, conversions implícites, nullability incerta).
• Transaccions: el codi legacy sovint conté suposicions d’commit implícit (tancar un Dataset, patrons semblants a AutoCommit, Cached Updates). Amb FireDAC convé una gestió conscient de transaccions, perquè millora la consistència funcional.
• Cursor/Fetch: FireDAC té defaults diferents i més paràmetres configurables. Patrons ineficients (resultsets grans per a llistes UI) es fan més visibles però poden ser optimitzats específicament.
• Unicode: a les versions modernes de Delphi Unicode és l’estàndard. La cadena de FireDAC (Client‑Library, Connection‑Options, DB‑Collation, tipus de camp) ha d’estar alineada, sinó apareixen problemes de caràcters i comparacions.
• Desplegament: segons la BD necessitareu biblioteques client (per exemple libpq per a PostgreSQL). Això cal planificar‑ho d’hora per evitar sorpreses en entorn de producció.

Imatge objectiu per una arquitectura FireDAC: estable, testable, ampliable

Una substitució de BDE no ha de derivar en «FireDAC per tot arreu i d’una manera qualsevol». Una imatge objectiu sòlida és especialment útil quan l’aplicació ha de continuar creixent o s’ha d’integrar en serveis/portals.

Objectiu mínim: capa d’Connection unificada

En lloc de tenir connexions disperses als formularis convé una capa central de connexió:

• Creació i configuració de TFDConnection en un punt central
• Timeouts, Encoding/CharacterSet i maneig d’errors unificats
• Canvi entre Dev/Test/Prod sense treball manual addicional
• Opcional: activació central de tracing/monitoring per casos de diagnosi

Recomanat: límits de transacció clars a la lògica de negoci

Moltes aplicacions antigues reparteixen modificacions de dades a través d’esdeveniments de UI. Això augmenta el risc d’actualitzacions parcials i dificulta les proves. Un enfocament robust amb FireDAC és: el Use Case (Servei/Lògica de negoci) inicia i finalitza la transacció, no la UI. Fins i tot en una aplicació VCL d’escriptori això crea un nucli estable que posteriorment es pot reutilitzar més fàcilment com a servei o API.

Escalable cap a serveis i REST

Si en el futur s’afegeix un REST-Server, es despleguen serveis Windows o Linux o es vol connectar un portal de clients, un data‑layer net és avantatjós. FireDAC és apte per això si el management de connexions, el maneig d’errors i —segons la càrrega del servidor— el pooling són considerats ja com a imatge objectiu. No cal implementar‑ho tot en el primer pas, però l’arquitectura no hauria d’impedir‑ho.

Estratègia de migració: introduir FireDAC de manera gradual i desmantellar BDE controladament

En entorns B2B un Big Bang rara vegada és realista: massa processos de negoci, massa responsabilitat operativa i poca tolerància a downtimes llargs. Una substitució gradual de BDE sol ser el camí segur.

Fase 1: inventari i mapa de riscos

Una inventari útil no només compta components, sinó que avalua comportaments i acoblaments:

• Quines bases de dades s’utilitzen: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• On hi ha accessos amb TTable, on s’usa SQL via TQuery, on hi ha Stored Procedures?
• Com es gestionen avui les transaccions (explícit, implícit, Cached Updates, patrons mixtes)?
• Quins informes/exports depenen d’especificitats de Dataset (ordenació, filtres, Calculated Fields)?
• Quines components de tercers o frameworks propis són específics de BDE?

A partir d’aquest mapa s’aprecia si la substitució afecta „només“ l’accés o si paral·lelament és necessari o recomanable un canvi de base de dades (p. ex. Paradox → SQL Server/PostgreSQL/MariaDB).

Fase 2: FireDAC‑Foundation (sense canviar la UI)

Abans de migrar pantalles convé que FireDAC estigui tècnicament ben posicionat:

• DataModule central o classe de servei amb TFDConnection
• Model de configuració per Connection Strings (p. ex. INI/JSON) i gestió de secrets neta
• Maneig d’errors estandarditzat (capturar DB‑Exceptions i transformar en missatges comprensibles i enregistrables)
• Opcions de tracing/monitoring per pilotar en producció (activables de manera selectiva, no perpetuament „sorolloses“)

És important que d’aquí surtin estàndards vinculants: convencions de noms, regles de paràmetres, esquema de logging, ajustos per defecte per cada BD.

Fase 3: mòdul pilot amb rellevància funcional veritable

Un bon pilot està delimitat funcionalment però és d’ús real. Objectiu: desenvolupar i verificar patrons.

• TQuery → TFDQuery (incloent paràmetrització i tipificació)
• Definir el marc de transaccions i fer‑lo visible al codi
• Demostrar equivalència de resultats (comparar resultsets amb rellevància funcional)
• Mesurar rendiment (temps de resposta, càrrega a la BD, trànsit de xarxa)

Al final del pilot hauria d’existir una checklist interna per migrar cada mòdul següent. Això redueix el risc i fa l’esforç més planificable.

Fase 4: migració global i neteja del desplegament

Després del pilot es fan canvis per mòduls. Paral·lelament es redueix la dependència operativa de BDE:

• Eliminar scripts d’instal·lador i documentació de configuracions de BDE
• Eliminar definicions d’Aliases, configuracions NetDir i rutes especials
• Alinear la pipeline de build/release amb les noves dependències (Client‑Libs, drivers)

Aquest desmantellament és essencial: mentre parts de BDE sobrevisquin al desplegament, el risc operatiu persisteix.

Peces amb possibilitat de fallada: causes comunes d’efectes secundaris funcionals

Moltes migracions no fallen per FireDAC en si, sinó per suposicions implícites en el codi antic. Aquestes àrees convé prioritzar‑les aviat.

Dialects SQL i SQL històricment cregut

Les aplicacions BDE sovint contenen SQL que amb un driver concret „funcionava per casualitat“: joins implícits, ús incoherent d’aliasses, funcions específiques de la BD, ordenacions incertes. En la migració cal:

• Fer l’SQL explícit (sintaxi JOIN en lloc de condicions implícites al WHERE)
• Comprovar mots reservats i identificadors (p. ex. DATE, USER, ORDER com a noms de camp)
• Uniformitzar o encapsular funcions de data/temps i de strings

FireDAC ofereix opcions d’adaptació, però la solució sostenible és SQL conforme a la BD i fàcilment llegible.

Mapeig de tipus: Boolean, Data/Temps, Memo/Blob, NULL

La BDE, en la pràctica, interpretava molt. FireDAC és més precís —una qualitat que exigeix regles. Temes típics:

• Boolean: BIT/SMALLINT/CHAR(1) — definir clarament a nivell de model, evitar conversions implícites
• Data/Temps: DATETIME vs. DATETIME2, milisegons, lògica d’ordenació/comparació; qüestions de zones horàries en sistemes distribuïts
• Memo/Blob: comportament de fetch (OnDemand), encoding, consum de memòria al client
• NULLability: codi antic que barreja strings buits i NULL porta a errors lògics difícils de detectar

Ha funcionat bé un catàleg de tipus concís: per cada taula/columna rellevant definir els tipus objectiu (BD i Delphi) i regles per NULL, valors per defecte i formatacions.

Transaccions: d’implícit a orquestrat conscient

En projectes legacy amb Delphi és habitual confiar en commits implícits (“si tanco el Dataset, ja està desat”). FireDAC exposa APIs clares (StartTransaction, Commit, Rollback). El benefici de la modernització arriba quan les transaccions es consideren marc funcional:

• El Use Case inicia la transacció
• Diverses actualitzacions es fan dins la mateixa Connection
• Commit/Rollback es realitzen de forma centralitzada amb maneig d’errors rastrejable

Això redueix incoherències i és crític si més endavant s’afegeixen serveis o interfícies a l’aplicació.

Cached Updates i maneig de conflictes (concurrency)

Moltes aplicacions BDE fan servir Cached Updates com a mecanisme d’edició offline. FireDAC pot reproduir mecanismes similars, però cal explicitar les regles:

• Quins camps són claus i quins s’utilitzen per a la comprovació de concurrency?
• Com es resolen els conflictes (RowVersion/Timestamp, „last write wins“, decisió de l’usuari)?
• Què passa quan hi ha errors parcials en operacions batch?

En moltes modernitzacions és recomanable portar la lògica de conflictes més a prop de la lògica de negoci o a una capa de servei, en lloc d’amagar‑la únicament en el comportament del Dataset de la UI.

Aplicacions centrades en TTable/Paradox: FireDAC no és l’única qüestió

Si l’aplicació depèn molt de l’accés basat en fitxers (TTable contra Paradox), dir que „substituïm BDE per FireDAC“ és només una part de la veritat. FireDAC està pensat principalment per bases de dades SQL. La decisió central és: modernitzarem la persistència cap a una BD de servidor?

• Migració a SQL Server, PostgreSQL o MariaDB
• Introducció d’un concepte de rol/privilegis i processos nets de backup/restore
• Operació multiusuari estable sense problemes de bloqueig de fitxers

Si un canvi immediat de BD no és possible organitzativament, sovint convé un procediment en dues etapes: primer estabilitzar la capa d’accés i reduir l’acoblament de la UI, després migrar les dades amb una estratègia de proves i cutover definida.

Reporting, exports i components de tercers

Els informes solen dependre de detalls: ordenacions, ordre de filtres, camps calculats, comportament Master/Detail. Per a una transició controlada:

• Identificar informes crítics i tractar‑los com a suite de proves de regresió
• Generar conjunts de dades per informes de manera determinística (Views/Stored Procedures o queries clarament definides)
• Reduir cadenes de filtres a la UI que depenen del comportament del Dataset

L’objectiu és obtenir equivalència reproduïble de resultats, especialment per a informes amb requisits d’auditoria.

Millora d’arquitectura durant la migració FireDAC: desacoblament pragmàtic

El reemplaçament de BDE és una bona ocasió per treure l’accés a dades dels formularis i dels eventhandlers. Això no implica necessàriament un projecte de re‑arquitectura complet. Mesures moderades acostumen a generar un gran impacte.

Estructura objectiu pragmàtica (connectable a una arquitectura Layer-3)

• Connection/Unit‑of‑Work: gestiona Connection i transacció, proveeix objectes Query
• Repository/DAO: encapsula SQL i accés a dades per àrea funcional
• Service/Use Case: orquestra la lògica de negoci, validacions i el marc de transacció

Aquesta estructura és compatible amb una posterior Layer-3 Architektur i facilita projectes posteriors: interfícies REST, serveis en segon pla, clients multiplataforma o la integració amb portals.

Efecte important: menys efectes secundaris globals

Molts projectes BDE treballen amb data modules globals i estats implícits. FireDAC també pot funcionar així, però la modernització és més estable si els estats es localitzen: cicle de vida clar de Connection/Transacció, rutes d’errors reproducibles i menys „efectes col·laterals“ per estat global.

Rendiment i estabilitat: configurar FireDAC amb criteri

FireDAC és potent, però el rendiment és una combinació d’SQL, indexació, estratègia de fetch i gestió de connexions. En migracions sovint es veu que la BDE havia ocultat patrons ineficients perquè abans els volums eren més petits o el sistema funcionava localment.

Estrategies de fetch i llistes UI

• Carregar només les columnes necessàries (evitar SELECT *)
• Ordenació al servidor i filtres dirigits en lloc de cadenes client
• Per grans volums: paging o càrrega incremental
• Carregar camps LOB (Memo/Blob) només quan siguin realment necessaris

FireDAC ofereix opcions adients; l’important és decidir funcionalment quines dades necessita realment l’usuari en cada context.

Prepared Statements i parametrització

Les queries parametritzades no són només un estàndard de seguretat (evitar SQL‑Injection), sinó que també milloren la reutilització de plans en moltes bases de dades. A més, posen al descobert imprecisions de tipus en codi antic que es poden corregir de manera dirigida. En sistemes creixuts això suposa un guany de qualitat que es reflecteix en menys casos especials i millor diagnòstic.

Gestió de connexions: Desktop vs. Servei/REST

En clients d’escriptori clàssics sovint és pràctic tenir una Connection de llarga durada per client. En serveis o en servidors REST s’utilitzen patrons diferents: peticions de vida curta, accessos paral·lels, pooling de connexions. Si la substitució de BDE forma part d’una modernització més àmplia, cal tenir presents aquestes diferències en la imatge objectiu perquè les fases posteriors no hagin de tornar a començar per l’accés a dades.

Estrategia de proves i aprovació: demostrar equivalència de resultats

El principal risc en la substitució de BDE no és que l’aplicació deixi d’arrencar, sinó desviacions funcionals subtils: ordenacions, arrodoniments, maneig de NULL, límits de transacció, efectes laterals de triggers/constraints en BD modernes. Una estratègia de proves robusta inclou:

• Regressió SQL: executar consultes crítiques sobre dades de prova definides i comparar resultsets
• Proves de Use Case: verificar processos clau (p. ex. comptabilitzar, aprovar, anul·lar, import/export) amb valors esperats
• Proves multiusuari/estabilitat: comportament de bloquejos, deadlocks, timeouts, durada de transaccions
• Logging/Observability: registrar errors de BD de manera estructurada (codis d’error, context, query afectada), no només mostrar diàlegs d’error

Les empreses en treuen doble benefici: les proves asseguren la migració i constitueixen una base per desplegar canvis futurs al model de dades o a les interfícies de manera controlada.

Bases de dades objectiu en projectes FireDAC: opcions típiques

FireDAC és deliberadament ampli, però cada BD té regles pròpies. En modernitzacions, els destins següents són habituals:

SQL Server

Típic en paisatges IT dominats per Windows. Punts clau: tipus Unicode coherents (NVARCHAR), tipus de temps moderns (DATETIME2), estratègia clara d’Identity/Sequence, nivells d’aïllament definits i un maneig net dels bloquejos.

PostgreSQL

Fort en integritat i funcionalitats. En migracions cal tenir en compte: case‑sensitivity d’identificadors, tipus de dades (boolean/uuid/jsonb) i diferències de dialecte. FireDAC pot connectar PostgreSQL de manera productiva si les biblioteques client i el desplegament estan ben organitzats.

MariaDB/MySQL

Freqüent quan el software d’escriptori conviu amb components web o portals. Important: utf8mb4 de manera consistent, InnoDB com a engine i una estratègia d’indexació i transaccions clara. FireDAC suporta MariaDB/MySQL de forma fiable sempre que paràmetres i tipus quedin ben definits.

Independentment del destí, una substitució de BDE serà més estable si paral·lelament es defineixen estàndards de base de dades (versionat d’esquema, scripts de migració, rols/drets, backup/restore, monitoring).

Recomanacions pràctiques per una migració FireDAC planificable

Reduir dependències abans de canviar moltes components

Quan l’SQL i la lògica de Dataset estan incrustats en multitud de formularis, cada canvi costa molt. Un pas intermig que concentrï l’SQL en poques classes d’accés redueix la superfície de migració. A partir d’aquí, la substitució per FireDAC sol ser més ràpida i menys arriscada.

Migrar d’hora un procés transaccional central

Les „llistes simples“ són un inici còmode, però reduir el risc passa per migrar aviat un procés amb actualitzacions reals i dependències. Si transaccions, tipus de dades i rutes d’errors estan acurades en aquest punt, la resta de la migració es planifica millor.

Tractar el desplegament com una feina de primer ordre

El canvi de codi és només la meitat. Cal aclarir d’hora:

• Quines biblioteques/clients/drivers es necessiten per cada BD?
• Com es versionen i signen aquestes biblioteques (si escau) i com s’implementen?
• Com es gestionen els paràmetres de connexió i qui pot modificar‑los?
• Com és el procés de suport quan fallen accés a BD?

Utilitzar FireDAC com a ancoratge de modernització — sense començar de zero

La substitució és una oportunitat per palanques de qualitat enfocades: parametrització, límits de transacció, logging, textos d’error unificats. Això redueix costos d’operació i fa que extensions posteriors (interfícies, serveis) siguin menys arriscades, sense reinventar funcionalment l’aplicació.

Conclusió: la substitució de BDE per FireDAC és una modernització controlable — si es tracta com a tema d’arquitectura

La BDE ha sostingut moltes aplicacions Delphi durant anys. Avui, però, constitueix un risc estructural: per a 64‑bit, per a un desplegament estandarditzat, per a requisits de seguretat moderns i per a la integració amb bases de dades actuals. FireDAC és el successor adequat, però no com un „intercanvi de components d’una nit per l’altra“. La via segura és una migració gradual amb una foundation neta, un mòdul pilot, regles vinculants per a tipus de dades i transaccions i proves que demostrin l’equivalència de resultats.

Si voleu planificar la substitució de BDE de manera estructurada —incloent inventari, camí de migració i l’arquitectura objectiu amb FireDAC— el següent pas més raonable és una comprovació tècnica de les vostres condicions marc: https://net-base-software-gmbh.de/kontakt/