Erstatte Borland BDE med FireDAC: Veiledning for en trygg Delphi-modernisering uten Big Bang

I mange virksomheter er Borland Database Engine (BDE) fortsatt en del av forretningskritiske Delphi-applikasjoner: akkumulert faglogikk, UI-nære dataaksesser med TTable/TQuery, delvis fortsatt Paradox/dBase, delvis tidlige klient-/server-installasjoner. Virkeligheten er ofte: Programvaren kjører, brukerne kjenner prosessene, og i daglig drift finnes det ingen umiddelbar grunn til å «røre» systemet. Samtidig endres det tekniske underlaget: operativsystemer skjerpes, deployment standardiseres, 64‑bit forventes, og datalagring skal legges på databaseservere med ryddig tilgangs- og backup-konsept.

Nettopp her blir «erstatte Borland BDE med BDE-avløsning med native tilkobling» en strategisk moderniseringsoppgave. BDE-Ablosung mit nativer Anbindung er i dagens Delphi-versjoner den etablerte dataadgangen for moderne databaser. Den leverer konsistent oppførsel, robuste drivere, Unicode-støtte, monitoring/tracing og en arkitektur som kan betjene både desktop-klienter, tjenester og REST-servere. Overgangen er imidlertid sjelden en ren 1:1-komponentutskifting – særlig ikke når eksisterende applikasjoner over år har «innpriset» BDE-spesifikk oppførsel (transaksjonsantakelser, dataformater, filter/sorteringer, Cached Updates, tredjepartsrapporter).

Denne artikkelen fokuserer på praktisk fremgangsmåte: Hvordan erstatter du BDE med FireDAC uten å sette faglogikken i fare og uten å tvinge fram en Big‑Bang-relaunch? Du får en gjennomførbar modell, tekniske målbilder og pekere til typiske problemområder i driften.

Hvorfor BDE-avløsning i dag er mer enn teknisk vedlikehold

Så lenge en BDE-applikasjon fungerer, kan en avløsning fremstå som ren «kodeopprydding». I praksis oppstår presset likevel ofte fra drifts- og risikoaspekter.

Deployment, sikkerhetsbaselines og «no-touch»-klienter

BDE er historisk designet for lokal konfigurasjon (BDE Administrator, Alias-definisjoner, NetDir, delte konfigurasjonsfiler). I moderne miljøer er manuelle steg og maskinomfattende innstillinger vanskelig å forene med programvaredistribusjon, hardening og auditspor. FireDAC tillater langt mer kontrollerbare deploys, fordi tilkoblingsparametre og driverinnstillinger kan forvaltes nær applikasjonen.

64‑bit, Windows-modernisering og nye plattformmål

Senest når en applikasjon må kjøre i 64‑bit (minnebehov, driver-/Office-økosystem, ny maskinvare, terminalserver-strategier), blir BDE reelt en blocker. FireDAC støtter 32/64‑bit konsistent og er dermed en kjernekomponent i enhver Delphi Modernisering som ikke må feile på dataaksesslaget. For øvrig gjør det temaer som Windows 11 ARM64 og hybride klient-/tjenestearkitekturer planleggingen langt mer håndterbar.

Database-strategi: bort fra filbasert, mot serverbasert

Mange BDE-applikasjoner bærer fortsatt byrder fra Paradox/dBase-tiden. Disse filbaserte databasene er mer sårbare i flerbrukerdrift, vanskeligere å sikre administrativt og passer dårlig til dagens krav (roller/rettigheter, kryptering, overvåking, høy tilgjengelighet). FireDAC er ikke «den nye Paradox-driveren», men den moderne veien inn mot SQL Server, PostgreSQL, MariaDB og Firebird. I praksis er derfor BDE-avløsningen ofte startskuddet for å profesjonalisere datalagring og drift.

Vedlikeholdbarhet og diagnostikk i drift

En undervurdert kostnadsfaktor er feilsøking: sporadiske locking-problemer, inkonsistent cursor-adferd, vanskelig ettersporbare parameterkonverteringer eller nettverks-/sti-problematikk. FireDAC gir med logging, monitoring og klarere typatferd bedre utspring for reproduserbar feilanalyse. For virksomheter som skal drive en applikasjon langsiktig og utvide punktvis, er dette umiddelbar gevinst.

BDE vs. FireDAC: forskjeller som teller i migrasjonen

På papiret kan komponenter matches. I realiteten handler det om atferdsendringer som kan gi faglige sideeffekter. En kort orientering:

Komponent-mapping (som startpunkt)

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

De vanligste atferdsforskjellene

• Parametre og datatyper: FireDAC arbeider mer presist. „Det går nok“-SQL avdekkes raskere (f.eks. datoverdier som strenger, implisitte konverteringer, uklar nullability).
• Transaksjoner: Legacy-kode inneholder ofte implisitte commit-antakelser (dataset lukkes, AutoCommit-lignende mønstre, Cached Updates). Med FireDAC lønner det seg med bevisst transaksjonsstyring siden det forbedrer faglig konsistens.
• Cursor/Fetch: FireDAC har andre defaults og flere justeringsmuligheter. Ineffektive mønstre (store resultsett for UI-lister) blir mer synlige, men kan målrettet optimeres.
• Unicode: I moderne Delphi-versjoner er Unicode standard. FireDAC-kjeden (client-library, connection-options, DB-collation, felttyper) må være konsistent, ellers oppstår tegn- og sammenligningsproblemer.
• Deployment: Avhengig av DB kreves klientbiblioteker (f.eks. libpq for PostgreSQL). Dette må planlegges tidlig for å unngå overraskelser i produksjon.

Målbilde for en FireDAC-arkitektur: stabil, testbar, utvidbar

En BDE-avløsning bør ikke ende i «FireDAC overalt på en måte». Et bærekraftig målbilde er spesielt verdifullt hvis applikasjonen skal videreutvikles eller integreres i tjenester/portaler.

Minimumsmål: enhetlig connection-layer

I stedet for spredte forbindelser i skjemaer anbefales et sentralt connection-layer:

• Opprettelse og konfigurasjon av TFDConnection på ett sted
• Enhetlige timeouts, encoding/characterSet, feilhåndtering
• Veksling Dev/Test/Prod uten manuell etterarbeid
• Valgfritt: sentral aktivering av tracing/monitoring for diagnostikk

Anbefalt: klare transaksjonsgrenser i faglogikken

Mange gamle applikasjoner sprer dataendringer over UI-hendelser. Det øker risikoen for delvise oppdateringer og gjør testing vanskeligere. En stabil FireDAC-tilnærming er: Use Case (tjeneste/faglogikk) starter og avslutter transaksjonen, ikke UI. Selv i ren VCL-skrivebordsprogramvare gir dette en robust kjerne som senere lettere kan brukes som tjeneste eller API.

Utvidelsesretning mot tjenester og REST

Dersom man senere legger til en REST-server, drifter Windows- eller Linux-tjenester eller ønsker å koble et kundesystem, gir et rent datalag fordeler. FireDAC egner seg hvis connection-management, feilhåndtering og – avhengig av serverbelastning – pooling i det minste er tenkt inn i målbildet. Det behøver ikke implementeres i første steg, men arkitekturen må ikke blokkere det.

Migrasjonsstrategi: innfør FireDAC trinnvis, bygg ned BDE kontrollert

I B2B-miljøer er et Big Bang sjelden realistisk: for mange fagprosesser, for mye driftsansvar, for liten aksept for lange nedetider. En trinnvis BDE-avløsning er vanligvis den sikreste vei.

Fase 1: Kartlegging og risikokart

En brukbar inventarliste teller ikke bare komponenter, men vurderer atferd og koblinger:

• Hvilke databaser brukes: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
• Hvor forekommer TTable-aksesser, hvor brukes SQL via TQuery, hvor brukes Stored Procedures?
• Hvordan håndteres transaksjoner i dag (eksplisitt, implisitt, Cached Updates, blandede mønstre)?
• Hvilke rapporter/eksporter forventer bestemte dataset-egenskaper (sortering, filter, calculated fields)?
• Hvilke tredjepartskomponenter eller egne rammeverk er BDE-spesifikke?

Fra dette kartet avledes om avløsningen „bare“ gjelder tilgangslaget eller om en parallell databaseomlegging (f.eks. Paradox → SQL Server/PostgreSQL/MariaDB) er hensiktsmessig eller nødvendig.

Fase 2: FireDAC-foundation (uten UI-omlegging)

Før du migrerer skjermer, bør FireDAC være teknisk solid etablert:

• Sentralt DataModule eller serviceklasse med TFDConnection
• Konfigurasjonsmodell for connection strings (f.eks. INI/JSON) og ryddig secrets-håndtering
• Standardisert feilhåndtering (DB-exceptions oversettes til forståelige, loggbare meldinger)
• Tracing/monitoring-alternativer for pilotdrift (aktivér målrettet, ikke kontinuerlig «høyt»)

Viktig er at dette fører til bindende standarder: navnekonvensjoner, parameterregler, logging-skjema, default-innstillinger per database.

Fase 3: Pilotmodul med reell fagrelevans

En god pilot bør være faglig avgrenset, men i faktisk bruk. Målet: utvikle og verifisere mønstre.

• TQuery → TFDQuery (inkl. parameterisering og typisering)
• Definere transaksjonsramme og gjøre den synlig i koden
• Bevise resultatlikhet (sammenligne faglig relevante resultsett)
• Måle ytelse (respons, DB‑last, nettverkstrafikk)

Ved pilotens slutt bør en intern sjekkliste foreligge som standard for etterfølgende moduler. Det reduserer risiko og gjør innsats mer forutsigbar.

Fase 4: Volummigrasjon og opprydding i deployment

Etter piloten migreres modulvis. Parallelt bygges BDE ned som driftsavhengighet:

• Fjern installer-skript og dokumentasjon for BDE-oppsett
• Eliminer alias-definisjoner, NetDir-konfigurasjon og spesialstier
• Justér build-/release-pipeline for nye avhengigheter (client-libs, drivere)

Netopp denne nedbyggingen er essensiell: så lenge BDE-deler overlever i deployet, vedvarer driftsrisikoen.

Snubletråder: vanlige årsaker til faglige sideeffekter

Mange migrasjoner feiler ikke på FireDAC i seg selv, men på implisitte antakelser i gammel kode. Følgende områder bør prioriteres tidlig.

SQL-dialekter og historisk opparbeidet SQL

BDE-applikasjoner inneholder ofte SQL som «tilfeldigvis» fungerte med en gitt driver: implisitte joins, uensartet aliasbruk, DB-spesifikke funksjoner, uklare sorteringer. I migrasjonen gjelder:

• Gjør SQL eksplisitt (JOIN-syntaks i stedet for implisitt WHERE‑kobling)
• Sjekk reserved words og identifierbruk (f.eks. DATE, USER, ORDER som feltnavn)
• Enhetliggjør eller kapsle datums-/tids- og strengfunksjoner

FireDAC tilbyr tilpasningsmuligheter, men den langsiktige riktige løsningen er DB-kompatibel, lesbar SQL.

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

BDE har i praksis tolket mye. FireDAC er mer presis – det er fordelaktig, men krever regler. Typiske tema:

• Boolean: BIT/SMALLINT/CHAR(1) – definer faglig tydelig, unngå implisitte konverteringer
• Dato/tid: DATETIME vs. DATETIME2, millisekunder, sorterings-/sammenligningslogikk; tidssoneaspekter i distribuerte systemer
• Memo/Blob: Fetch-adferd (OnDemand), encoding, klientminnebruk
• NULLability: Gammel kode som blander tomme strenger og NULL fører til vanskelig synlige logikkfeil

En slank datatypekatalog har vist seg nyttig: for hver faglig viktig tabell/kolonne måltyper (DB og Delphi) pluss regler for NULL, standardverdier og formatering.

Transaksjoner: fra implisitt til bevisst orkestrert

I legacy-Delphi-prosjekter er en vanlig feil at systemet har stolt på implisitte commits („når jeg lukker datasetet, er det lagret“). FireDAC tilbyr klare APIer (StartTransaction, Commit, Rollback). Moderniseringsgevinsten kommer når transaksjoner forstås som et faglig rammeverk:

• Use Case starter transaksjon
• Flere oppdateringer skjer innen samme Connection
• Commit/Rollback skjer sentralt med etterprøvbar feilhåndtering

Dette reduserer inkonsistenser og er avgjørende når applikasjonen senere skal utvides med tjenester eller grensesnitt.

Cached Updates og konfliktbehandling (concurrency)

Mange BDE-applikasjoner bruker Cached Updates som en «offline-edit»-mekanikk. FireDAC kan tilby tilsvarende, men reglene må være eksplisitte:

• Hvilke felter er nøkler, hvilke tjener concurrency-sjekk?
• Hvordan løses konflikter (RowVersion/Timestamp, „last write wins“, brukerbeslutning)?
• Hva skjer ved delvise feil i batch-operasjoner?

I moderniseringer er det ofte fornuftig å flytte konfliktlogikk nærmere faglogikken eller inn i en tjenestelag i stedet for å skjule den i UI-datasetatferd.

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

Hvis applikasjonen i stor grad baserer seg på filtilgang (TTable mot Paradox), er «BDE gjennom FireDAC» bare en del av sannheten. FireDAC er primært rettet mot SQL-databaser. Den sentrale beslutningen er da: Skal datalagringen moderniseres til en server-DB?

• Migrasjon til SQL Server, PostgreSQL eller MariaDB
• Innføring av rolle-/rettighetskonsept og ryddige backup/restore-prosesser
• Stabil flerbrukerdrift uten fil-locking-problemer

Hvis et umiddelbart databaseskifte er organisatorisk umulig, er en todelt tilnærming ofte pragmatisk: først stabilisere tilgangslaget og redusere UI-koplinger, deretter gjennomføre datamigrasjon med klar test- og cutover-strategi.

Reporting, eksport og tredjepartskomponenter

Rapporter er ofte avhengige av detaljer: sorteringer, filterrekkefølger, beregnede felter, master/detail-adferd. For en kontrollert omstilling:

• Identifiser kritiske rapporter og behandle dem som en regressjonstest-suite
• Produser deterministiske datasett for rapporter (views/stored procedures eller klart definerte queries)
• Reduser UI-side filterkjedene som avhenger av dataset-adferd

Målet er reproduserbar resultatlikhet, spesielt for revisjonsrelevante analyser.

Arkitektur‑oppgradering i forbindelse med FireDAC-migrasjonen: pragmatisk løsrivelse

BDE-avløsningen er et godt tidspunkt for å ta dataaksess ut av skjemaer og event-handlere. Det betyr ikke at et fullstendig re‑arkitekturprosjekt er nødvendig. Allerede moderate tiltak gir ofte betydelig effekt.

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

• Connection/Unit-of-Work: forvalter Connection og transaksjon, leverer query-objekter
• Repository/DAO: kapsler SQL og dataaksess per fagområde
• Service/Use Case: orkestrerer faglogikk, valideringer og transaksjonsramme

Denne strukturen er kompatibel med en senere Layer-3 arkitektur og forenkler oppfølgingsprosjekter: REST-grensesnitt, bakgrunnstjenester, multiplattform‑klienter eller kobling til portaler.

Viktig effekt: færre globale sideeffekter

Mange BDE-prosjekter bruker globale datamoduler og implisitte tilstander. FireDAC kan fungere slik også, men moderniseringen blir mer stabil hvis tilstander lokaliseres: klart livssyklus for Connection/Transaksjon, reproduserbare feilstier, færre «bivirkninger» fra global tilstand.

Ytelse og stabilitet: konfigurér FireDAC målrettet

FireDAC er kraftig, men ytelse er en kombinasjon av SQL, indeksering, fetch-strategi og connection-management. I migrasjoner viser det seg ofte at BDE har skjult ineffektive mønstre fordi datamengdene tidligere var mindre eller systemet kjørte lokalt.

Fetch-strategier og UI-lister

• Lister laster kun nødvendige kolonner (unngå SELECT *)
• Serverside sortering og målrettede filter i stedet for klient-side kjeder
• Ved store datamengder: paging eller inkrementell lasting
• LOB-felt (Memo/Blob) lastes først når de faktisk trengs

FireDAC tilbyr passende innstillinger; avgjørende er faglig beslutning om hvilke data en bruker faktisk trenger i konteksten.

Prepared statements og parametrisering

Parametriserte queries er ikke bare sikkerhetsstandard (unngå SQL‑injection), men forbedrer også gjenbruk av plan i mange databaser. I tillegg synliggjøres typeuregelmessigheter i gammel kode og kan korrigeres målrettet. Spesielt i modne systemer er dette et kvalitetsløft som gir færre spesialtilfeller og bedre diagnostikk.

Connection-management: Desktop vs. tjeneste/REST

I klassiske desktop-klienter er ofte en langlivede Connection per klient praktisk. I tjenester eller REST-servere er andre mønstre vanlige: kortvarige forespørsler, parallelle aksesser, connection-pooling. Den som ser BDE-avløsningen som del av en større modernisering, bør ta hensyn til disse forskjellene i målbildet, slik at senere utvidelser ikke må starte på nytt ved dataaksesslaget.

Test- og akseptstrategi: dokumenter resultatlikhet

Ved BDE-avløsningen er hovedrisikoen sjelden «applikasjonen starter ikke», men subtile faglige avvik: sorteringer, avrunding, NULL-håndtering, transaksjonsgrenser, bivirkninger fra triggere/constraints i moderne DBer. En bærekraftig teststrategi inkluderer:

• SQL-regresjon: kjør kritiske spørringer mot definerte testdata og sammenlign resultsett
• Use-case-tester: kontroller kjerneprosesser (f.eks. bokføring, godkjenning, kansellering, import/eksport) mot forventede utfall
• Flerbruker-/stabilitetstester: sperreatferd, deadlocks, timeouts, transaksjonsvarighet
• Logging/observability: fange DB-feil strukturert (feilkoder, kontekst, berørt query), ikke bare «feil‑dialog»

Virksomheter vinner dobbelt: Testene sikrer migrasjonen og etablerer et grunnlag for at senere endringer i datamodell eller grensesnitt kan rulles ut kontrollert.

Mål‑databaser i FireDAC-prosjekter: typiske alternativer

FireDAC er bevisst bredt, men hver database har egne regler. Følgende mål er vanlige i moderniseringer:

SQL Server

Typisk i Windows-dominerte IT-landskap. Viktige punkter: konsistente Unicode-typer (NVARCHAR), moderne tidspunktstyper (DATETIME2), klar identity/sequence‑strategi, definerte isolation levels og bevisst håndtering av låsing.

PostgreSQL

Sterk på integritet og funksjonalitet. I migrasjoner relevante emner: identifier-case-sensitivity, datatyper (boolean/uuid/jsonb) og dialektforskjeller. FireDAC kan tilkoble PostgreSQL produktivt, forutsatt at klientbiblioteker og deployment er ryddig organisert.

MariaDB/MySQL

Vanlig når desktop-programvare inngår i samspill med web- eller portal-komponenter. Viktig: konsekvent bruk av utf8mb4, InnoDB som engine, ryddig transaksjons- og indeksstrategi. FireDAC støtter MariaDB/MySQL pålitelig når parametre og typer er klart definert.

Uavhengig av mål gjelder: En BDE-avløsning lykkes best når parallelle database‑standarder innføres (schema‑versjonering, migrasjonsskript, roller/rettigheter, backup/restore, monitoring).

Praktiske anbefalinger for en planbar FireDAC‑migrasjon

Reduser avhengigheter før du bytter massevis av komponenter

Når SQL og dataset-logikk ligger i mange skjemaer, blir hver endring kostbar. Et mellomtrinn som samler SQL i få tilgangsklasser reduserer migrasjonsflaten betydelig. Deretter går selve overgangen til FireDAC ofte raskere og med lavere risiko.

Migrer tidlig en transaksjonell kjerneprosess

„Enkle lister“ er praktiske å begynne med, men risikoreduserende er det å tidlig migrere en prosess med reelle oppdateringer og avhengigheter. Når transaksjoner, datatyper og feilstier er ryddet der, blir resten av migrasjonen mer forutsigbar.

Behandle deployment som likeverdig arbeid

Kodeendringen er bare halve jobben. Avklar tidlig:

• Hvilke klientbiblioteker/drivere kreves per database?
• Hvordan versjoneres og signeres disse, og hvordan rulles de ut?
• Hvordan forvaltes connection-parametre, og hvem har rett til å endre dem?
• Hvordan ser supportprosessen ut når DB-tilgang feiler?

Bruk FireDAC som moderniseringsanker – uten nystart

Avløsningen er en anledning for målrettede kvalitetsløft: parametrisering, transaksjonsgrenser, logging, enhetlige feiltekster. Dette reduserer driftskostnader og gjør senere utvidelser (grensesnitt, tjenester) betydelig mindre risikofylte, uten at applikasjonen må gjenoppfinnes faglig.

Konklusjon: BDE-avløsning med FireDAC er kontrollert modernisering – hvis den behandles som et arkitekturtema

BDE har båret mange Delphi-applikasjoner i årevis. I dag er den imidlertid en strukturell risiko: for 64‑bit, for standardisert deployment, for moderne sikkerhetskrav og for tilknytning til tidsriktige databaser. FireDAC er en passende etterfølger, men ikke som en «komponentutskifting over natten». Den sikre kursen er en gradvis migrasjon med en ryddig foundation, pilotmodul, bindende regler for datatyper og transaksjoner samt tester som dokumenterer resultatlikhet.

Hvis du ønsker å planlegge BDE-avløsningen strukturert – inkludert inventaranalyse, migrasjonsvei og FireDAC-målarkitektur – er en teknisk avstemming av dine rammebetingelser det fornuftigste neste steget: https://net-base-software-gmbh.de/kontakt/