Erstat Borland BDE med FireDAC: En vejledning til en sikker Delphi-modernisering uden Big Bang

I mange virksomheder er Borland Database Engine (BDE) stadig en del af forretningskritiske Delphi-applikationer: opbygget faglogik, UI-nære dataadgange med TTable/TQuery, delvist stadig Paradox/dBase, delvist tidlige klient/server-installationer. Ofte er realiteten: Softwaren kører, brugerne kender processerne, og i daglig drift er der ingen umiddelbar grund til at “røre ved det”. Samtidig ændrer det tekniske fundament sig: Operativsystemer bliver hårdnakket, udrulning standardiseres, 64‑Bit forventes, og datalagring skal foregå på databaseservere med et ordentligt rettigheds- og backup-koncept.

Lige her bliver “erstatte Borland BDE med en BDE-afløser med native tilslutning” til en strategisk moderniseringsopgave. BDE-Ablosung mit nativer Anbindung er i aktuelle Delphi-versioner den etablerede dataadgang til moderne databaser. Det leverer konsistent opførsel, robuste drivere, Unicode-understøttelse, overvågning/tracing og en arkitektur, der kan betjene både desktop-klienter, services og REST-servere. Overgangen er dog sjældent blot en 1:1-komponentudskiftning – især ikke når bestående applikationer igennem årene har indbygget BDE-specifik opførsel (transaktionsantagelser, dataformater, filter/sorteringer, Cached Updates, tredjeparts-rapporter).

Denne artikel fokuserer på den praktiske fremgangsmåde: Hvordan erstatter I BDE med FireDAC uden at sætte faglogikken på spil og uden at tvinge en Big-Bang-relancering? I får en anvendelig model, tekniske målarkitekturer og henvisninger til typiske problemzoner i driften.

Hvorfor BDE-afløsnin­gen i dag er mere end teknisk vedligehold

Så længe en BDE-applikation fungerer, virker en afløsnin­gen som ren “kodeoprydning”. I praksis opstår presset dog typisk ud fra drift- og risikospørgsmål.

Udrulning, sikkerhedsbaselines og “No-Touch”-klienter

BDE er historisk designet til lokal konfiguration (BDE Administrator, Alias-definitioner, NetDir, fælles konfigurationsfiler). I moderne miljøer er manuelle trin og maskinbrede indstillinger vanskeligt forenelige med softwaredistribution, hårdning og auditabilitet. FireDAC tillader langt mere kontrollerbare udrulninger, fordi forbindelsesparametre og driverindstillinger kan administreres nær applikationen.

64‑Bit, Windows-modernisering og nye platformmål

Senest når en applikation skal køre i 64‑Bit (hukommelsesbehov, driver-/office-økosystem, ny hardware, terminalserver-strategier), bliver BDE reelt en blocker. FireDAC understøtter 32/64‑Bit konsekvent og er dermed en kernekomponent i enhver Delphi-modernisering, der teknisk ikke må fejle på dataadgangen. Ved siden af bliver emner som Windows 11 ARM64 og hybride klient/service-arkitekturer overhovedet planbare.

Database­strategi: væk fra filbaseret, hen imod serverbaseret

Mange BDE-applikationer bærer stadig arv fra Paradox/dBase-tiden. Disse fildatabaser er ved flerbrugerdrift mere sårbare, sværere at administrere og passer dårligt til nutidens krav (roller/rettigheder, kryptering, overvågning, høj tilgængelighed). FireDAC er ikke “den nye Paradox-driver”, men den moderne adgang til SQL Server, PostgreSQL, MariaDB og Firebird. I praksis er BDE-afløsnin­gen derfor ofte startskuddet til at professionalisere datalagring og drift.

Vedligeholdelse og diagnostik i drift

En undervurderet omkostningsfaktor er fejlsøgning: sporadiske locking-problemer, inkonsistent cursor-opførsel, svært gennemsigtige parameterkonverteringer eller netværks-/sti-problemer. FireDAC tilbyder med logging, overvågning og klarere typologi bedre muligheder for reproducerbar fejlanalyse. For virksomheder, der vil drive en applikation langfristet og udvide punktvist, er det en umiddelbar fordel.

BDE vs. FireDAC: forskelle, der tæller i migrationen

På papiret kan komponenter matches. I virkeligheden handler det om opførselsændringer, der kan give faglige sideeffekter. En kort orientering:

Komponent-mapping (som udgangspunkt)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (i moderniseringer ofte bedre: query-/view-baseret adgang)
• TStoredProc (BDE) → TFDStoredProc

De hyppigste opførselsafvigelser

• Parametre og datatyper: FireDAC arbejder mere præcist. “Det går nok”-SQL afsløres hurtigere (fx datoværdier som strenge, implicitte konverteringer, uklar nullability).
• Transaktioner: Legacy-kode indeholder ofte implicitte commit-antagelser (dataset lukke, AutoCommit-lignende mønstre, Cached Updates). Med FireDAC betaler det sig at styre transaktioner bevidst, fordi det forbedrer faglig konsistens.
• Cursor/Fetch: FireDAC har andre standarder og flere justeringsmuligheder. Ineffektive mønstre (store resultatsæt til UI-lister) bliver mere synlige, men kan målrettet optimeres.
• Unicode: I moderne Delphi-versioner er Unicode standard. FireDAC-kæden (client-library, connection-options, DB-collation, felttyper) skal være konsistent, ellers truer tegn- og sammenligningsproblemer.
• Deployment: Afhængigt af DB kræves klientbiblioteker (fx libpq til PostgreSQL). Det skal planlægges tidligt, ellers opstår overraskelser tæt på produktion.

Målbillede for en FireDAC-arkitektur: stabil, testbar, udbyggelig

En BDE-afløsnin­gen bør ikke ende i “FireDAC overalt på slump”. Et holdbart målbillede er særligt værdifuldt, hvis applikationen skal videreudvikles eller indlejres i services/portaler.

Minimumsmål: ensartet connection-layer

I stedet for spredte forbindelser i formularer anbefales et centralt connection-layer:

• Oprettelse og konfiguration af TFDConnection ét sted
• Ensartede timeouts, encoding/charset, fejlbehandling
• Skift mellem Dev/Test/Prod uden manuel efterarbejde
• Valgfrit: central aktivering af tracing/monitoring til diagnose

Anbefalet: klare transaktionsgrænser i faglogikken

Mange ældre applikationer fordeler dataændringer over UI-events. Det øger risikoen for delvise opdateringer og gør tests sværere. En stabil FireDAC-tilgang er: Use Case (service/faglogik) starter og afslutter transaktionen, ikke UI. Selv i ren VCL-desktopsoftware skaber det en robust kerne, der senere lettere kan bruges som service eller API.

Udvidelsesvenlig mod services og REST

Hvis man senere supplerer med en REST-server, kører Windows- eller Linux-services eller kobler et kundeportal på, drager man fordel af et rent datalayer. FireDAC er velegnet, hvis connection-management, fejlbehandling og – afhængig af server-load – pooling som minimum er tænkt ind i målbildet. Det behøver ikke implementeres i første skridt, men arkitekturen bør ikke blokere det.

Migrationsstrategi: indfør FireDAC trinvist, nedbyg BDE kontrolleret

I B2B-miljøer er et Big Bang sjældent realistisk: for mange fagprocesser, for stort driftsansvar, for lidt accept af lange nedetider. En trinvist BDE-afløsnin­gen er som regel den sikre vej.

Fase 1: statusopgørelse og risikokort

En brugbar inventarliste tæller ikke kun komponenter, men vurderer opførsel og koblinger:

• Hvilke databaser anvendes: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Hvor forekommer TTable-adgange, hvor bruges SQL via TQuery, hvor anvendes stored procedures?
• Hvordan håndteres transaktioner i dag (eksplicit, implicit, Cached Updates, blandede mønstre)?
• Hvilke rapporter/eksport forventer bestemte dataset-egenskaber (sortering, filter, calculated fields)?
• Hvilke tredjepartskomponenter eller eget frameworks er BDE-specifikke?

Fra dette kort fremgår, om afløsnin­gen “kun” berører adgangslaget, eller om en parallel databasestrukturændring (fx Paradox → SQL Server/PostgreSQL/MariaDB) er fornuftig eller nødvendig.

Fase 2: FireDAC-foundation (uden UI-omstilling)

Før I migrerer skærmbilleder, bør FireDAC stå teknisk solidt:

• Centralt DataModule eller service-klasse med TFDConnection
• Konfigurationsmodel for connection-strings (fx INI/JSON) og ordentlig håndtering af secrets
• Standardiseret fejlbehandling (DB-exceptions oversættes til forståelige, logbare meddelelser)
• Tracing/monitoring-optioner til pilotdrift (målrettet aktiverbart, ikke permanent “støjende”)

Vigtigt er, at dette udmunder i bindende standarder: navnekonventioner, parameterregler, logging-skema, default-indstillinger pr. database.

Fase 3: pilotmodul med reel fagrelevans

Et godt pilotområde er fagligt afgrænset, men reelt brugt. Målet: udvikle og verificere mønstre.

• TQuery → TFDQuery (inkl. parameterisering og typning)
• Definere transaktionsrammer og gøre dem synlige i koden
• Påvise resultatlighed (sammenligne fagligt relevante resultatsæt)
• Måle performance ( svartider, DB-load, netværkstrafik)

Ved pilotens afslutning bør der foreligge en intern tjekliste, som hvert efterfølgende modul migreres efter. Det reducerer risiko og gør indsatsen planbar.

Fase 4: omfattende migration og oprydning af deployment

Efter piloten migreres modul for modul. Parallel nedbrydes BDE som driftsafhængighed:

• Fjern installer-scripts og dokumentation for BDE-opsætninger
• Eliminer alias-definitioner, NetDir-konfiguration og særlige stier
• Tilpas build-/release-pipeline til nye afhængigheder (client-libs, drivere)

Netop denne oprydning er essentiel: Så længe BDE-dele overlever i deploymenten, består driftsrisikoen.

Stolperfelter: hyppige årsager til faglige sideeffekter

Mange migrationer fejler ikke på FireDAC, men på implicitte antagelser i ældrekoden. Disse områder bør prioriteres tidligt.

SQL-dialekter og historisk opbygget SQL

BDE-applikationer indeholder ofte SQL, som “tilfældigvis” virkede med en bestemt driver: implicitte joins, uens alias-brug, DB-specifikke funktioner, uklare sorteringer. I migrationen gælder:

• Gør SQL eksplicit (JOIN-syntax i stedet for implicit WHERE-forbindelse)
• Tjek reserverede ord og identifierer (fx DATE, USER, ORDER som feltnavne)
• Harmoniser eller kapsl datums-/tid- og stringfunktioner

FireDAC tilbyder justeringsmuligheder, men den holdbare løsning er DB-konform, læsbar SQL.

Datatypemapping: Boolean, dato/tid, Memo/Blob, NULL

BDE har i praksis tolket meget. FireDAC er mere præcis – hvilket er godt, men kræver regler. Typiske emner:

• Boolean: BIT/SMALLINT/CHAR(1) – definér fagligt klart, ingen implicitte konverteringer
• Dato/Tid: DATETIME vs. DATETIME2, millisekunder, sorterings-/sammenligningslogik; tidszone-spørgsmål ved distribuerede systemer
• Memo/Blob: Fetch-adfærd (OnDemand), encoding, hukommelsesforbrug i klient
• NULLability: Ældrekode, der blander tomme strenge og NULL, fører til svære logikfejl

Et slankt datatypekatalog har vist sit værd: for hver vigtig tabel/kolonne må der være måldata- og Delphi-typemål samt regler for NULL, default-værdier og formateringer.

Transaktioner: fra implicit til bevidst orkestreret

I legacy-Delphi-projekter er en hyppig fejl, at systemet har baseret sig på implicitte commits (“hvis jeg lukker datasættet, er det gemt”). FireDAC tilbyder klare API’er (StartTransaction, Commit, Rollback). Moderniseringsfordelen opstår, når transaktioner forstås som faglige rammer:

• Use Case starter transaktion
• Flere opdateringer kører inden for samme connection
• Commit/Rollback håndteres centralt med efterprøvelig fejlbehandling

Det reducerer inkonsistenser og er afgørende, hvis applikationen senere udvides med services eller interfaces.

Cached Updates og konfliktbehandling (konkurrence)

Mange BDE-applikationer bruger Cached Updates som “offline-edit”-mekanisme. FireDAC kan lignende, men reglerne må være eksplicite:

• Hvilke felter er nøgler, hvilke bruges til concurrency-check?
• Hvordan løses konflikter (RowVersion/Timestamp, “last write wins”, brugerbeslutning)?
• Hvad sker der ved delvise fejl i batch-operationer?

I moderniseringer er det ofte fornuftigt at flytte konfliktlogik tættere på faglogikken eller ind i en service-lag i stedet for kun at lade den ligge i UI-dataset-opførslen.

TTable/Paradox-tunge applikationer: FireDAC er ikke hele løsningen

Hvis applikationen i høj grad er bygget på filbaseret adgang (TTable mod Paradox), er “erstat BDE med FireDAC” kun en del af sandheden. FireDAC er primært beregnet til SQL-databaser. Den centrale beslutning er derfor: Skal datalagring moderniseres til en server-DB?

• Migration til SQL Server, PostgreSQL eller MariaDB
• Indførelse af roller/rettighedskoncept og ordentlige backup/restore-processer
• Stabil flerbrugerdrift uden fil-locking-problemer

Hvis et øjeblikkeligt databasebytte organisatorisk ikke er muligt, er en todelt tilgang ofte pragmatisk: først stabilisere adgangslaget og reducere UI-koblingen, så data-migrationen gennemføres med klar test- og cutover-strategi.

Rapportering, eksport og tredjepartskomponenter

Rapporter afhænger ofte af detaljer: sorteringer, filterrækkefølge, beregnede felter, master/detail-adfærd. For en kontrolleret omstilling:

• Identificer kritiske rapporter og behandl dem som en regressions-testsuite
• Generér datasæt til rapporter deterministisk (views/stored procedures eller klart definerede queries)
• Reducer UI-baserede filterkæder, som afhænger af dataset-opførsel

Målet er reproducerbar resultatlighed, især for auditrelevante udtræk.

Arkitektur-opgradering i forbindelse med FireDAC-migration: pragmatisk afkobling

BDE-afløsnin­gen er et godt tidspunkt at trække dataadgangen ud af formularer og eventhandlers. Det betyder ikke, at et komplet re-architecture-projekt er nødvendigt. Selv moderate tiltag giver ofte stor effekt.

Pragmatisk målstruktur (tilslutbar til Layer-3-arkitektur)

• Connection/Unit-of-Work: styrer connection og transaktion, stiller query-objekter til rådighed
• Repository/DAO: indkapsler SQL og dataadgang pr. fagligt område
• Service/Use Case: orkestrerer faglogik, valideringer og transaktionsramme

Denne struktur er kompatibel med en senere Layer-3 arkitektur og letter efterfølgende projekter: REST-grænseflader, baggrundsservices, multiplatform-klienter eller kobling til portaler.

Vigtig effekt: færre globale sideeffekter

Mange BDE-projekter arbejder med globale datamoduler og implicitte tilstande. FireDAC fungerer også sådan, men moderniseringen bliver mere stabil, hvis tilstande lokaliseres: klart lifecycle for connection/transaktion, reproducerbare fejlveje, færre “bivirkninger” fra global tilstand.

Performance og stabilitet: konfigurer FireDAC målrettet

FireDAC er kraftfuld, men performance er en kombination af SQL, indeksering, fetch-strategi og connection-management. I migrationer viser det sig ofte: BDE har skjult ineffektive mønstre, fordi datamængder tidligere var mindre eller fordi systemet kørte lokalt.

Fetch-strategier og UI-lister

• Indlæs kun nødvendige kolonner til lister (ingen SELECT *)
• Server-side sortering og målrettede filtre i stedet for klient-side kæder
• Ved store datamængder: paging eller inkrementel efterindlæsning
• LOB-felter (Memo/Blob) indlades kun når nødvendigt

FireDAC tilbyder passende muligheder; afgørende er den faglige beslutning om, hvilke data en bruger reelt behøver i den givne kontekst.

Prepared statements og parameterisering

Parametriserede queries er ikke bare en sikkerhedsstandard (undgå SQL-injection), men forbedrer også i mange databaser genbrug af execution-plans. Derudover synliggør det typemisbrug i ældrekode, som kan rettes målrettet. I voksede systemer er det en kvalitetsforbedring, som giver færre specialtilfælde og bedre diagnostik.

Connection-management: desktop vs. service/REST

I klassiske desktop-klienter er en langlivede connection per klient ofte praktisk. I services eller REST-servere gælder andre mønstre: kortlivede forespørgsler, parallel adgang, connection-pooling. Hvis BDE-afløsnin­gen ses som en del af en større modernisering, bør disse forskelle tænkes ind i målbildet, så senere udvidelser ikke starter forfra ved dataadgangen.

Test- og acceptstrategi: påvis resultatlighed

Ved BDE-afløsnin­gen er hovedrisikoen sjældent “applikationen starter ikke”, men snarere stille faglige afvigelser: sorteringer, afrundinger, NULL-håndtering, transaktionsgrænser, bivirkninger fra triggers/constraints i moderne DB’er. En levedygtig teststrategi omfatter:

• SQL-regression: kør kritiske forespørgsler mod definerede testdata og sammenlign resultatsæt
• Use-case-tests: test kerneprocesser (fx bogføring, frigivelse, annullering, import/eksport) mod forventede resultater
• Flerbruger-/stabilitetstests: låseadfærd, deadlocks, timeouts, transaktionsvarighed
• Logging/observability: registrér DB-fejl struktureret (fejlkoder, kontekst, pågældende query) og ikke kun som “fejl-dialog”

Virksomheder får dobbelt udbytte: Testene sikrer migrationen og skaber et fundament for at rulle senere ændringer i datamodel eller interfaces kontrolleret ud.

Måldatabaser i FireDAC-projekter: typiske muligheder

FireDAC er bevidst bredt understøttende, men hver database har egne regler. I moderniseringer er følgende mål ofte brugt:

SQL Server

Typisk i Windows-dominerede IT-landskaber. Vigtige punkter: konsistente Unicode-typer (NVARCHAR), moderne tidstyper (DATETIME2), klar identity-/sequence-strategi, definerede isolation levels og ordentlig håndtering af låsninger.

PostgreSQL

Stærk på integritet og features. I migrationer relevant: identifier-case-sensitivity, datatyper (boolean/uuid/jsonb) og dialektforskelle. FireDAC kan forbinde PostgreSQL produktivt, hvis client-libraries og deployment er ordentligt organiseret.

MariaDB/MySQL

Ofte valgt når desktop-software skal samarbejde med web- eller portal-komponenter. Vigtigt: konsekvent brug af utf8mb4, InnoDB som engine, klar transaktions- og indexstrategi. FireDAC understøtter MariaDB/MySQL pålideligt, når parametre og typer er klart defineret.

Uanset mål gælder: En BDE-afløsnin­gen bliver mest stabil, hvis der parallelt indføres database-standarder (schema-versionering, migrations-scripts, roller/rettigheder, backup/restore, overvågning).

Praktiske anbefalinger for en planbar FireDAC-migration

Reducer afhængigheder, før I masseskifter komponenter

Hvis SQL og dataset-logik er spredt i mange formularer, bliver hver ændring dyr. Et mellemtrin, hvor SQL samles i få adgangsklasser, reducerer migrationsfladen markant. Derefter er selve omstillingen til FireDAC ofte hurtigere og mindre risikofyldt.

Flyt tidligt et transaktionelt kerneproces

“Enkle lister” er lette som start, men det reducerer risikoen mest at migrere tidligt en proces med rigtige opdateringer og afhængigheder. Når transaktioner, datatyper og fejlveje er på plads der, bliver resten af migrationen mere forudsigelig.

Behandl deployment som ligestillet opgave

Kodeomstillingen er kun halvdelen. Afklar tidligt:

• Hvilke client-libraries/drivere kræves per database?
• Hvordan versionsstyres og signeres disse (hvis relevant) og hvordan rulles de ud?
• Hvordan forvaltes connection-parametre, og hvem må ændre dem?
• Hvordan ser supportprocessen ud, når DB-adgang fejler?

Brug FireDAC som moderniseringsanker – uden at starte forfra

Afløsnin­gen er en anledning til målrettede kvalitetsløft: parameterisering, transaktionsgrænser, logging, ensartede fejltekster. Det reducerer driftsomkostninger og gør senere udvidelser (interfaces, services) markant mindre risikofyldte, uden at applikationen fagligt må genopfindes.

Konklusion: BDE-afløsnin­gen med FireDAC er kontrollerbar modernisering – hvis den behandles som et arkitekturtema

BDE har båret mange Delphi-applikationer i årevis. I dag er den dog en strukturel risiko: for 64‑Bit, for standardiseret deployment, for moderne sikkerhedskrav og for tilslutning til tidssvarende databaser. FireDAC er den passende efterfølger, men ikke som “komponentudskiftning natten over”. Den sikre vej er en trinvist migration med en solid foundation, pilotmodul, bindende regler for datatyper og transaktioner samt tests, der påviser resultatlighed.

Hvis I vil planlægge BDE-afløsnin­gen struktureret – inklusive statusanalyse, migrationssti og FireDAC-målarkitektur – er en teknisk afstemning af jeres rammebetingelser det mest fornuftige næste skridt: https://net-base-software-gmbh.de/kontakt/