Erstatte Borland BDE med FireDAC: Avveiningskart for en sikker migrering

Mandag morgen, 08:15. En nylig rullet ut Windows-oppdatering, en ny endepunktbeskyttelse, i tillegg et „lite“ pakke fra programvaredistribusjonen – og plutselig står et lokasjon stille. En forretningskritisk Delphi-applikasjon starter riktignok, men ved første dataadgang kommer „Alias ikke funnet“ eller „Ugyldig nettverksbane“. I sakshistorikken dukker begreper opp som i mange IT-team for lengst ikke har en fast plass: BDE-administrator, NetDir, lokale konfigurasjonsfiler som ligger „et sted“ og virker „på en måte“.

Den som vil erstatte Borland BDE med BDE-erstatning med native tilkobling, har som regel ikke luksusproblemet „vi moderniserer for moro skyld“, men en reell målkonflikt. Mål 1: maksimal stabilitet i daglig drift, ingen overraskelser i bokføringskjøringer, rapporter eller grensesnitt. Mål 2: løfte applikasjonen ut av legacy-unntaket – bort fra sårbar klientkonfigurasjon, mot en dataadgang som passer for 64‑Bit, Unicode, sikkerhetsbaselines og en ren database-strategi. Dette veiekartet plasserer nytte, innsats, risikoer og begrensninger, og viser for hvem hvilken beslutning er plausibel.

Målkonflikt som utgangspunkt: Beholde stabilitet eller investere i fremtiden?

Mål A: Stabilitet, fordi prosessen avhenger av det

Mange BDE-baserte applikasjoner er operativt innkjørt. Support kjenner særegenhetene, fagavdelinger har vendt seg til bestemte skjermflyter og lister, og selv skjeve kanter er tatt høyde for. Nettopp derfor er en endring i dataadgangen risikabel: Feil viser seg ofte ikke som en krasj, men som en stille avvik – en annen sortering, en annen avrunding, en annen håndtering av NULL-verdier, et uventet langt lås. For IT-ledelse og drift betyr det: Migrering er bare forsvarlig dersom resultatlikhet og rollback er realistisk sikret.

Mål B: Fremtidsdyktighet, fordi drift og plattform ikke står stille

Samtidig er Borland Database Engine (BDE) ikke «bare gammel», men offisielt avviklet (deprecated). Embarcadero påpeker uttrykkelig at BDE ikke lenger blir videreutviklet og for eksempel aldri vil få Unicode-støtte; for eksisterende applikasjoner anbefales migrering til BDE-Ablosung mit nativer Anbindung.^[Quelle] Praktisk konsekvens: Jo mer konsekvent dere hardner klienter, distribuerer programvare, begrenser rettigheter og standardiserer plattformer, desto mindre passer en dataadgang som er avhengig av historiske globale innstillinger og en foreldet driververden. Dette gjelder ikke bare „IT-Estetikk“, men også hendelsesrisiko og planbarhet.

Hva som virkelig endres, når dere erstatter Borland BDE med FireDAC

I mange prosjektplaner står det i praksis: TDatabase blir TFDConnection, TQuery blir TFDQuery, TTable blir TFDTable. Det er den synlige delen. Den relevante delen ligger under: BDE har over år båret med seg implisitte antakelser (konverteringer, standard-sorteringer, transaksjonelle bivirkninger, konfigurasjonssteder). FireDAC er som regel strengere, mer transparent og tettere på den aktuelle databasen. Det forbedrer vedlikeholdbarhet og diagnostikk – men tvinger dere til å dokumentere og teste antakelsene.

Fire forskjeller som merkes i drift og fagavdeling

• Konfigurasjon og Deployment: BDE-oppsett har historisk brukt globale alias-/NetDir-konfigurasjoner og filer som kan variere per maskin eller per profil. FireDAC kan konfigureres nært forbindelsen og styres bedre per miljø, men krever avhengig av database passende klientbiblioteker og en klar oppdaterings- og distribusjonsstrategi.
• Datatyper, parametre, implisitt konvertering: FireDAC er ofte mer presis. SQL som «tilfeldigvis» fungerte (dato som streng, tall som tekst) blir lettere synlig. Det er positivt – forutsatt at dere oppdager feilene i test, ikke i månedsavslutningen.
• Unicode og Collation (sortering/tegnsettingsregler): Hvis applikasjonen historisk bruker ANSI-logikk, kan en modernisering synliggjøre tegn- og sammenligningsproblemer: sortering, store/små bokstaver, umlaute, eksportformater. Dette er løsbart, men ikke automatisk «identisk».
• Transaksjoner og låseatferd: Mange legacy-mønstre er avhengig av datasettdrevne bivirkninger. FireDAC tilbyr ren transaksjonskontroll – men krever at dere definerer hvor transaksjoner starter og slutter.

Avveiningskart: nytte, innsats, risiko og begrensninger

Når migrasjonen er spesielt aktuell

Når utrulling og sikkerhetshardening regelmessig kolliderer

Jo mer standardisert klientlandskapet deres er (programvaredistribusjon, begrensede rettigheter, segmenterte nettverk, endepunktsbeskyttelse), desto mer blir alt som er konfigurert «per maskin» eller «per brukerprofil» synlig, og som ved feil bare kan rettes ved manuell gjenskapning. FireDAC tvinger dere ikke automatisk til en god konfigurasjonsmodell, men det passer bedre til en tilnærming der tilkoblingsparametere per miljø defineres, versjoneres og dokumenteres.

Når 64‑bit-planlegging eller ny maskinvare er aktuell

Mange selskaper bytter ikke på grunn av en IDE-versjon, men fordi terminalservere fornyes, nye operativsystemversjoner kommer eller sikkerhetspolicyer skjerpes. Da blir datatilgang et hardt avhengighetspunkt. Ved å modernisere den løsrives etterfølgende prosjekter: Neste plattform- eller infrastrukturtiltak trenger ikke samtidig å løse datatilgangsproblemet.

Når datalagring uansett skal «modnes»

I filbaserte scenarier (klassisk Paradox/dBase) er den største risiko sjelden UI. Det er locking, realitetene rundt sikkerhetskopiering, dataintegritet, rettigheter og flerbrukerdrift. FireDAC er primært laget for SQL-databaser og klare transaksjonsmodeller. Hvis en serverbasert databasestrategi uansett er aktuell, er BDE-erstattelse ofte tidspunktet for å planlegge begge samtidig – med alle konsekvenser for drift (backups, overvåking, vedlikeholdsvinduer, rolle-/rettighetskonsept).

Tre migrasjonsveier – med svært ulike risikoprofiler

Alternativ 1: Mekanisk «kompilere på nytt» (kun som mellomsteg)

Embarcadero beskriver i Upgrade/Migration Center en typisk FireDAC-migrasjon som en flerstegsprosess og nevner også «reFind» som et verktøy som hjelper med den mekaniske delen: erstatte komponenter, oppdatere uses-klausuler, gjøre grunnleggende endringer for å kunne kompilere igjen.^[Kilde] Som et delmål er det nyttig. Som avslutning er det for lite, fordi kompilering ikke sier noe om faglig likhet, ytelse under belastning eller concurrency.

Alternativ 2: Innkapsle datatilgang, deretter bytte (ofte det beste kompromisset)

I stedet for å bygge om hvert skjema direkte, samler dere datatilgangen i noen få ansvarlige steder: tilkoblingsopprettelse, sentral feilhåndtering, logging/tracing, bindende parameter- og transaksjonsregler. Deretter migrerer dere modulvis. Det reduserer migrasjonsflaten og gjør godkjenning og drift mer planbare, fordi oppførsel kan observeres og korrigeres på ett sted.

Alternativ 3: FireDAC + databasebytte (stor gevinst, men høyere krav til styring)

Hvis det uansett er planlagt et hopp fra filbasert til serverbasert, kan det være effektivt å koble begge endringene. Gevinsten er stor (transaksjoner, rettigheter, overvåking, bedre driftsprosesser). Prisen er at dere må ta mer enn «tekniske» beslutninger: datamigrasjon, skjema-design, cutover, parallellkjøring, tilbakefallsstrategi. Uten klart godkjenningsformat og driftsavtaler blir denne løypa fort et langvarig prosjekt.

En praksisnær fremgangsmåte i 7 trinn (uten Big Bang)

1. Kartlegging som risikokart: Hvilke datakilder, hvilke tilgangsmetoder (TTable-dominert vs. SQL), hvilke kritiske rapporter, hvilke batchkjøringer, hvilke import-/eksportgrensesnitt avhenger av datasettets oppførsel?
2. Bestem målmodus: „FireDAC på samme database“ eller „FireDAC pluss modernisering av databasen“. Dette er en portefølje- og driftsbeslutning, ikke bare et utviklerspørsmål.
3. Definer grunnlaget: Sentral tilkoblingskonfigurasjon, timeouts, feilhåndtering, valgfritt aktiverbart tracing/logging. Mål: reproduserbart i Dev/Test/Prod.
4. Velg pilotprosess: Ikke det minste skjemaet, men en faglig tydelig avgrenset prosess med lesing og skriving (transaksjoner, låsing, validering) og klare akseptansekriterier.
5. Påvis likhet i resultater: Sammenligning av resultsett, rapporter og kjerneindikatorer på definerte testdata. Fokus: NULL, datologikk, avrundinger, tegnsett, sortering.
6. Migrasjon i bølger: Etter moduler/brukstilfeller, med release-ring (pilotgruppe, supportvindu, rollback-pakke, kommunikasjon). Parallell-drift er tillatt, men teknisk tydelig adskilt.
7. BDE i deploy fase ut: Fjern installerprogram, dokumentasjon, konfigurasjonsRESTer. Så lenge BDE „for alle tilfeller“ forblir forhåndsinstallert, vedvarer også en del av driftsrisikoen.

Typiske risikosoner – og hvordan man får dem administrativt under kontroll

1) Datatyper, NULL og „historiske“ konverteringer

Mange modne Delphi-applikasjoner inneholder grenseflater som lenge ingen har rørt: tomme strenger i stedet for NULL, tall i tekstfelt, dato som streng, „0“ som false. FireDAC ødelegger ikke slike steder automatisk, men gjør dem mer synlige. For drift og fagavdeling er det en fordel, fordi feil blir mer reproduserbare – hvis dere fastsetter regler: Hvilke kolonner kan være NULL? Hvilke default-verdier gjelder faglig? Hvordan lagres booleaner? Hvilken tidsoppløsning er relevant (dato vs. timestamp)?

2) Transaksjoner, låser og samtidighet

I BDE-altstrukturer oppstår transaksjoner ofte „ved siden av“: Datasett åpnes, bruker klikker, på et tidspunkt postes det. Ved serverbaserte databaser kan dette føre til lange transaksjoner og unødvendige låser. Ved en FireDAC-migrasjon lønner det seg å følge en enkel hovedtanke: transaksjoner hører til rundt brukstilfellet, ikke rundt UI. Det kan bety at lagringsoperasjoner samles, valideringer utføres tidligere og feilhåndtering sentraliseres.

3) SQL-dialekt, reserverte ord, deterministisk sortering

En del av arbeidet er ikke „FireDAC“, men SQL-hygiene. BDE har historisk tolerert en del: uklare aliasnavn, implisitte joins, ikke-deterministisk sortering. FireDAC er her ikke motstanderen, men forsterkeren: problemer blir synlige. Den robuste løsningen er nesten alltid å gjøre SQL eksplisitt. Det er også nyttig for administratorer, fordi spørringer da blir enklere å analysere (behov for indekser, kjøreplaner, belastningstester).

4) Rapportering, eksport, revisjonsrelevante analyser

Når rapporter brukes for månedsavslutning, fakturering eller revisjonsrelevante analyser, er skjulte avvik den egentlige risikoen. Behandle derfor kritiske rapporter som egne produktkomponenter: definerte testdata, forventede summer/radantall, dokumentert filterlogikk, godkjenning av fagavdelingen. Der det er mulig, stabiliser datagrunnlaget (f.eks. gjennom klart definerte spørringer eller views) i stedet for å akseptere UI-side filterkjeder som sannhet.

Arkitekturkonsekvenser: Hva FireDAC muliggjør – og hva som ikke oppstår automatisk

God basis for tjenester, jobber og grensesnitt

Mange selskaper utvider desktop-systemer med REST-tjenester, bakgrunnsbehandling eller portaler. En moderne dataaksess passer inn, hvis tilkoblingslivssyklus, feilhåndtering og transaksjoner er rent kapslet. Uten denne kapslingen oppstår bare „en ny driver i gammel struktur“ – og hvert påfølgende prosjekt bygger igjen egne regler.

FireDAC erstatter ikke avkobling mellom UI og forretningslogikk

Dersom skjemaer i dag bygger opp SQL, forretningsregler ligger i eventhandlere og globale tilstander dominerer, forblir dette i første omgang etter migrasjonen. FireDAC er ikke et arkitekturtiltak, men en god anledning til å følge opp med en minimal struktur: sentral tilkoblingsadministrasjon, få tilgangsklasser per fagmodul, definerte feil- og transaksjonsregler. Det er ofte tilstrekkelig til å gjøre vedlikehold og drift betydelig mer forutsigbart.

Grenser og spesialtilfeller du bør ta opp tidlig

Sterkt TTable-/Paradox-drevne systemer

Hvis porteføljen er sterkt filbasert, er det egentlige spørsmålet ikke „BDE eller FireDAC“, men «hvilken datalagring». FireDAC er ikke ment å bevare en filbasert verden mest mulig uendret. Den som må modernisere Paradox-data, bør planlegge innsatsen for datamigrasjon, skjema-design, rettigheter, Backup/RESTore-tester og Cutover grundig – inkludert parallell drift og datasynkronisering hvis et hardt skille faglig ikke er mulig.

Parallell drift er et verktøy, ikke en sluttstatus

Ja, BDE og FireDAC kan kjøre parallelt. Prisen er kompleksitet: dobbel konfigurasjon, doble feilmønstre, flere avhengigheter. Sett derfor tidlig en sluttdato for avviklingen av BDE-nedbyggingen og definer skillelinjen (moduler, brukstilfeller, tekniske lag). Halv-halv uten et mål blir som regel dyrere i drift enn en målrettet ombygging i faser.

Hvilke beslutninger IT-ledelse og drift bør fastsette tidlig

• Miljøstrategi: Hvordan håndterer dere Dev/Test/Prod-konfigurasjoner? Hvem får endre tilkoblingsparametere? Hvordan håndterer dere hemmeligheter?
• Driver- og oppdateringspolitikk: Hvordan versjoneres og distribueres klientbiblioteker? Finnes det release-ringer og en fallback-mulighet?
• Observerbarhet: Hvilke logger trenger driften ved hendelser? Hvilke SQL-kontekster kan logges av personvern- eller sikkerhetsgrunner?
• Akseptanseformat: Hvilke kjerneprosesser må dekkes som regresjonstester (lister, bokføringer, eksporter, rapporter)?
• Rollback-plan: Hva er tilbakefallsstrategien per bølge – teknisk (pakker), organisatorisk (kommunikasjon) og datamessig (ingen datatap)?

Hovedfaktor som avgjør suksess: Tillit gjennom påvisning

De fleste migrasjoner mislykkes ikke på «tilkoblingen», men på tilliten. Tillit oppstår når dere kan vise at kritiske prosesser forblir faglig identiske – eller når avvik er bevisst besluttet og tydelig kommunisert. Nettopp her ligger muligheten ved omstillingen: den tvinger fram eksplisitte regler (sortering, datatyper, transaksjoner) og skaper dermed et grunnlag som fortsatt er vedlikeholdbart og driftbart om to år. FireDAC er da ikke målet, men middelet for å bringe drift og videreutvikling tilbake til en planbar normaltilstand.

Hvis dere ønsker å forberede avhendingen strukturert (risikokart, pilot, test- og utrullingsplan), kan dere starte tiltaket her på en ryddig måte: drøft prosjekt eller moderniseringsinitiativ med Net-Base.

For dette temaet er også Delphi modernisering og FireDAC migrering viktige. Artikkelen setter disse aspektene i en tydelig kontekst og viser hva som er viktig i praksis.

Drøft prosjekt eller moderniseringsinitiativ med Net-Base.