Fra magasinets tema til projektpraksis
Passende service- og tekniske sider til artiklen
En BDE-Ablösung står ikke på ønskelisten i mange virksomheder – men på et tidspunkt på risikokortet. Borland Database Engine (BDE) er en historisk dataadgangsstack til Delphi-applikationer, som i etablerede miljøer ofte stadig håndterer Paradox-tabeller eller ældre databaseforbindelser. Så længe alt „på en eller anden måde fungerer“, virker emnet håndterbart. I praksis er det dog som regel drift, opdateringer og grænseflader, der svigter først: 64-bit-migrationer, nye Windows-versioner, moderne databaser, sikkerhedskrav, Terminalserver/VDI eller ganske enkelt ønsket om stabil og gennemskuelig administration.
Denne artikel placerer, hvor en BDE-baseret applikation realistisk kan fejle i dag, hvordan du planlægger udskiftningen, så data, grænseflader og processer fortsætter med at fungere, og hvilke migrationsveje der har vist sig effektive i praksis. Fokus er ikke „kodekosmetik“, men driftssikkerhed, datakvalitet, vedligeholdelsesvenlighed og muligheden for trinvis modernisering af applikationen – uden unødvendig Big-Bang.
Hvorfor BDE i drift bliver et problem
BDE er ikke blot „gammel“, men går i flere henseender ikke længere i tråd med aktuelle IT-standarder. Det viser sig sjældent ved et enkelt stort sammenbrud, men i mange små friktioner, der koster IT-teams tid og øger risikoen.
Tekniske og organisatoriske symptomer
- Ustabile eller vanskeligt vedligeholdelige klientinstallationer: BDE-konfiguration, alias-håndtering, stier, skriveadgange og afhængigheder er ofte ikke let at pakke. I Terminalserver- eller VDI-opsætninger eskalerer disse problemstillinger hurtigt.
- Driver- og kompatibilitetsgrænser: Moderne databaser og sikkerhedskonfigurationer (fx TLS-standarder, autentificeringsmetoder) kan ikke længere afbildes robust via BDE-Connectivity.
- 32-/64-Bit-konflikter: Mange virksomheder ønsker af gode grunde 64-bit-klienter, nye Office-versioner, moderne print-/PDF-stacks eller ARM64-enheder. BDE bliver derved en flaskehals.
- Sikkerhed og hardening: Gamle datapaths, lokale filer, uklare adgangskrav, manglende krypterings- eller audit-funktioner passer dårligt til nutidens sikkerheds- og compliance-forventninger.
- Manglende fremtidssikring af grænseflader: Når APIs (REST), central identity (fx SAML 2.0 som standard for Single Sign-on) eller servicebaseret integration kræves, virker en BDE-kerne som et anker på legacy-klienten.
Afgørende: En BDE-Ablösung er sjældent „kun“ udskiftning af en biblioteksfil. Den berører datamodeller, transaktioner, locking (låseadfærd), samtidighed, fejlbehandling, deployments og ofte også rettighedsmodellen.
BDE-Ablösung realistisk einordnen: Was genau wird ersetzt?
I eksisterende applikationer er „BDE“ som regel en samlebetegnelse. For en pålidelig planlægning skal det være klart, hvilke roller BDE spiller i det konkrete system:
- Dataadgangslag: Datasæt, forespørgsler, kald til stored procedures, cursor-adfærd, parameterbinding.
- Driver-/forbindelseslag: Tilslutning til Paradox, dBASE, InterBase/Firebird eller også SQL Server/Oracle via ældre driver-stier.
- Konfiguration: BDE-administrator, Aliases, NetDir, lokale stier, fælles mapper.
- Semantik: Hvordan låses der? Hvordan fortolkes dato-/talformater? Hvilke felttyper og indekser er historisk blevet anvendt?
For IT-ledelse og administration er denne afklaring forskellen mellem en „lille opdatering“ og et struktureret moderniseringsprojekt. Først derefter kan man beslutte, om en ren modernisering af dataadgangen er tilstrækkelig, eller om samtidig en databasemigration eller arkitektur-hygiejne er fornuftig.
Målarkitekturer efter BDE: typiske veje
Der findes ikke én erstatning. I praksis har tre veje etableret sig, som også kan kombineres:
1) Direkte skifte til FireDAC med eksisterende database
BDE-Ablosung med nativer tilslutning er et moderne dataadgangsbibliotek for Delphi, som understøtter forskellige databaser og drivere og i daglig drift er tydeligt mere automatiserbart end BDE-konfigurationer. Denne vej egner sig, når databasen i sig selv er robust, og den primære risiko ligger i det gamle adgangslag. Det er vigtigt at teste forbindelsesparametre, transaktioner og typeafbildninger (f.eks. String/Unicode, dato/tid) grundigt.
2) Migration fra Paradox/filbaseret til Client-Server (PostgreSQL, SQL Server, MariaDB)
Hvis der stadig bruges Paradox-tabeller eller andre filbaserede strukturer, er BDE-Abløsning ofte det rette tidspunkt til at gå til en central database. Client-Server betyder her: transaktioner sikres på serversiden, sikkerhedskopier kan styres centralt, rettigheder kan defineres på DB-niveau, og samtidige adgangshåndteringer kan drives mere kontrolleret. For drift og security er det som regel den største løftestang.
3) Afkobling via services: REST-API foran den eksisterende logik
I stedet for at bygge klienten fuldstændigt om med det samme, kan en REST-service (REST steht für „Representational State Transfer“, ein verbreiteter Stil für HTTP-basierte Schnittstellen) fungere som et integrationslag. Dermed kan portaler, eksterne systemer eller nye moduler tilsluttes, uden at hver adgang kommer direkte fra den legacy-klient. Denne vej er særlig nyttig, hvis applikationen skal vokse trinvis i retning af en modulær arkitektur.
Forarbejde, der afgør succes eller stilstand
En BDE-Abløsning fejler sjældent på grund af teknisk umulighed, men på grund af manglende transparens i data og processer. Følgende forarbejde reducerer projekt- og driftsrisiko mærkbart.
Statusopgørelse: data, funktioner, drift
- Datainventar: Hvilke tabeller, filer, indekser, referencer og specialfelter findes? Hvor store er datamængderne, hvor hurtigt vokser de, og hvor ligger de i dag?
- Transaktionsgrænser: Hvor forventer fagprocessen „alt eller intet“? Hvor er der hidtil stiltiende blevet levet med delvise opdateringer?
- Batch- og baggrundsprocesser: Import/eksport, rapportering, PDF-udtræk, natlige kørsler, integrationsjobs. Disse dele er ved migrationer ofte de reelle årsager til nedetid.
- Driftsbillede: Hvordan deployes der (MSI, Copy-Deploy, softwaredistribution)? Hvilke rettigheder kræves på klienterne? Hvilke logs findes? Hvordan håndteres support?
I denne fase er det værd at inddrage administrationsviden bevidst: „Hvad sker der ved en klientudskiftning?“, „Hvordan reagerer vi på korrupte data?“, „Hvor lang tid tager en gendannelse?“ – det er de spørgsmål, der senere afgør rollout’en.
Datar kvalitet og implicitte regler synliggøres
Tekniske kerneemner ved BDE-udskiftning
For beslutningstagere fremstår „udskiftning af dataadgang“ ofte som en lige linje. I praksis findes der en række tekniske justeringspunkter, der direkte påvirker drift, stabilitet og supportindsats.
Datatyper, Unicode og sortering
Mange legacy-applikationer bærer arv fra ANSI-tiderne. Ved modernisering skal tegnsæt, sorteringsrækkefølge (collation), case-sensitivitet og specialtegn (umlauter, ß) defineres entydigt. Ellers opstår „spøgelsesfejl“: søgninger giver manglende eller forskellige hits, dubletter opstår, og eksporter afviger. En Unicode-migration er derfor ofte en del af udskiftningen – ikke nødvendigvis som et Big Bang, men som en bevidst planlagt etape.
Transaktioner og låseadfærd (Locking)
Filbaseret datalagring opfører sig anderledes end client-server. I SQL-databaser bestemmer isoleringsniveauer, row locks og deadlock-håndtering konkurrenceforholdene. For driften betyder det: Man skal kende til hvilke operationer der kører længe, hvilke tabeller der er „hotspots“ og hvor man arbejder med relevante indekser, kortere transaktioner eller optimerede forespørgsler. Her betaler et ordentligt monitoring sig, frem for kun at konstatere „det føles langsomt“.
Fejlscenarier: Fra klientdialog til kontrolleret logging
Mange ældre applikationer viser databasefejl direkte i dialoger eller skriver få anvendelige meddelelser. Efter BDE-udskiftningen bør fejl være centralt eftersporbart: Hvilken query, hvilken bruger, hvilken handling, hvilken databasemelding? For administration er det afgørende, at fejl kan afgrænses reproducerbart, uden at man skal „pille“ ved individuelle klienter. I servicebaserede dele supplerer strukturerede logs (fx JSON) og korrelations-ID’er for at kunne følge requests på tværs af komponenter.
Deployment og konfiguration: væk fra alias-vildvækst
Et ofte gentaget mål er at ensrette konfigurationen: Forbindelsesindstillinger ikke længere per klient i BDE-administratoren, men centralt eller i det mindste standardiseret via konfigurationsfiler/Registry-indstillinger, der sættes via softwaredistribuering. For terminalservere er det særligt vigtigt. Også certifikater, TLS-parametre og proxy-konfigurationer bør ikke vedligeholdes „manuelt“.
Migreringsstrategi: Trinvis i stedet for Big Bang
En udskiftning kan gennemføres i etaper. Det reducerer nedetidsrisikoen og tillader tidlige forbedringer i driften, mens applikationen fortsat er i brug.
Etape 1: Stabil dataadgang som en udskiftelig lag
I mange Delphi-applikationer er dataadgang spredt på tværs af UI. Et praktisk mellemlag er et klart afgrænset dataadgangslag (ofte kaldet „Layer“; i en Layer-3-arkitektur adskilles UI, forretningslogik og dataadgang). Målet er ikke akademisk renhed, men vedligeholdbarhed: Når alle DB-tilgange samles få steder, kan drivere, parametre og transaktionshåndtering ændres konsekvent.
Etape 2: Parallelkørsel og sammenligningstests
Især ved datamigrationer er parallelkørsel guld værd: Et defineret datasæt overføres til den nye database, centrale Use-Cases testes mod begge systemer, og afvigelser analyseres systematisk. Det er vigtigt ikke kun at reducere testene til „åbne skærmbillede“, men også at inddrage bagvedliggende processer: Import/Export, Reporting, batchkørsel, print/PDF, rettighedstests.
Etape 3: Cutover med tilbagefaldsstrategi
Skiftet (Cutover) bør planlægges driftspraktisk: vedligeholdelsesvindue, datafreeze, definerede checklister, monitoring og et klart „rollback“-scenarie. Rollback betyder ikke, at man kan skifte frem og tilbage vilkårligt, men at man i problemtilfælde ordnet kan blive produktiv igen. Det omfatter backups, RESTore-øvelser og en plan for, hvordan man sikrer datakonsistens efter et tilbageslag.
Databasemigration i detaljer: hvad IT og drift bør være opmærksomme på
Når der i forbindelse med BDE-udskiftning fra Paradox eller andre filbaserede strukturer migreres til en central SQL-database, står IT-teams over for flere beslutninger, der senere vil præge driftsomkostninger og support.
Schema-Design: 1:1 overtage eller målrettet forbedre?
En 1:1-overførsel reducerer kortsigtet risiko, men bevarer ofte svagheder: manglende primærnøgler, uensartede datatyper, „semantik i strenge“, historisk opståede feltlængder. En realistisk tilgang er todelt: Først migrere stabilt (minimale ændringer), derefter konsolidere i kontrollerede trin. Det kræver versionsstyring af schemaet (Migrationen), så ændringer kan rulles ud sporbart.
Performance: Indekser og typiske forespørgsler tidligt teste
Paradox- og BDE-typiske adgangsmønstre passer sjældent 1:1 til SQL. Afgørende er tidligt at måle de vigtigste Use-Cases: søgeformularer, lister, bogføringer, batchkørsler. Deraf udledes indekser, forespørgselsoptimeringer og eventuelt materialiseringer. For administration er det væsentligt, at performance ikke opstår „tilfældigt“, men via måleværdier og efterprøvede tiltag.
Backup/RESTore og høj tilgængelighed
Med en central database ændrer spillereglerne sig: Backups skal være konsistente, regelmæssigt verificerede og hurtigt gendannelsesklare. RESTore-tests er ikke luksus, men grundlaget for robuste RTO/RPO-mål (RTO = tid til genoprettelse, RPO = maksimalt datatab i tid). Afhængigt af kritikalitet indgår replikation, standby-instanser eller klart regulerede vedligeholdelsesvinduer. En BDE-udskiftning er et godt tidspunkt til endelig at definere disse driftskrav.
Grænseflader og integration: den ofte undervurderede del
Mange bestående applikationer lever ikke isoleret. De fodrer et DMS, er tilknyttet ERP, leverer data til BI/Reporting eller kommunikerer med maskiner/værktøjer. Ved en BDE-udskiftning ændres grænseflader sjældent fagligt, men teknisk.
Stabilisering af Import/Export
Typiske fejlkilder er faste stier, lokale drev, Excel-formater, CSV-encoding og manglende validering. Ved en modernisering betaler det sig at behandle import/eksport som en defineret, testbar funktion: klar formatdefinition, protokollering, fejllister, genkørsel. Det reducerer supporttilfælde markant, fordi fejl ikke længere „stille“ glider igennem.
REST-APIs som integrationsanker
Når nye systemer skal tilkobles, er en REST-API ofte den pragmatiske vej. Vigtigt er ikke kun endepunkter, men driftsaspekter: autentificering (f.eks. token), ratebegrænsninger, logning, versionering af API’en og et koncept for Breaking Changes. En API, der rulles ud uden versionering, skaber senere unødvendige afhængigheder.
Sikkerhed og rettigheder efter afviklingen
Med afslutningen af BDE opstår muligheden for at gøre rettigheder mere konsistente. Ofte er rettigheder i legacy-systemer delvist implementeret i applikationen og delvist „gennem filstier“. Moderne målbilleder adskiller klart:
- Autentificering: Hvem er brugeren? (f.eks. Windows/AD, SSO via SAML 2.0)
- Autorisation: Hvad må brugeren i applikationen? (roller, rettigheder, lejere)
- Databaseadgangsrettigheder: Applikationsadgangen sker via tekniske DB-brugere, ikke via slutbruger-konti; følsomme admin-operationer er adskilt.
- Audit og sporbarhed: Vigtige ændringer bør kunne protokolleres (hvem, hvad, hvornår), uden at hver detalje drukner i logfilerne.
For IT-ledelse er det relevant: Sikkerhed skabes ikke gennem „flere dialoger“, men gennem klare ansvarsfordelinger og verificerbare regler. Netop dét bliver ved en struktureret BDE-afvikling ofte muligt for første gang.
Test- og rollout-plan: hvad der virkelig tæller i praksis
Ved moderniseringer er testbarhed et driftskriterium. Jo mindre reproducerbart, desto større supportindsats. En pragmatisk rollout-plan kombinerer tekniske og organisatoriske tiltag.
Testtyper, du bør planlægge
- Regressionstest af kerneprocesser: Bogføringer, stamdata, søgning, analyser, udskrift/PDF.
- Datavalidering: Stikprøver og automatiserede checks (antal, summer, referencer, dubletter).
- Belastnings-/performance-checks: ikke som en „benchmark“, men i forhold til reelle spidsbelastningstider og batchkørsler.
- Driftstests: Installation, update, rollback, logrotation, backup/restore, monitoring-events.
Pilotering og trinvist rollout
Et pilotprojekt med klart afgrænsede brugergrupper og definerede supportveje reducerer risikoen. Det er vigtigt at indsamle feedback struktureret: Hvilke fejl er egentlige defekter, hvilke er adfærdsændringer pga. sortering/Unicode, og hvilke er processpørgsmål? En ordentlig ticket- og prioriteringsproces forhindrer, at projektet ender i en „alt er lige vigtigt“-tilstand.
Hvornår betaler det sig særligt at afvikle BDE – og hvornår kræver det mere?
Der er klare udløsere, hvor tøven bliver dyrere end handling:
- Planlagt 64-bit-omstilling eller nye Windows-generationer i klientdrift
- Hyppige supporttilfælde på grund af klient-setup, stier, rettigheder eller terminalserver-miljøer
- Behov for central datalagring, sikker backup/restore og sporbare audits
- Nye krav til grænseflader (portaler, BI, eksterne partnere) og sikkerhed
Nogle gange er BDE-udskiftningen dog kun det første skridt: Hvis samtidig UI/UX, proceslogik eller adgangsmodellen grundlæggende må fornyes, bør projektet planlægges modulært. „Alt på én gang“ virker måske effektivt, men fører i mange virksomheder til lange freeze-faser og vanskeligt testbare mellemliggende tilstande. Bedre er en køreplan, der tidligt synliggør driftsfordele: stabil dataadgang, central database, bedre logs, og derefter gradvis yderligere modernisering (f.eks. portaler eller services).
Konklusion: BDE-udskiftning som kontrolleret moderniseringssti
En BDE-udskiftning er mere end ren teknisk refaktorering. Ved korrekt planlægning er det et kontrolleret skridt mod mere driftssikker business-software: standardiserede deployment-processer, dokumenteret datahåndtering, tydeligere grænseflader, forbedrede sikkerheds- og revisionsmuligheder samt mulighed for at tilslutte moderne arkitekturkomponenter som REST-services eller portaler. Nøglen er en pålidelig statusopgørelse, en trinvis migrationsstrategi og et rollout, der tager drift og datakvalitet lige så seriøst som funktionalitet.
Hvis I ønsker at vurdere jeres udskiftning struktureret og fastlægge en realistisk migrationssti, så tal med os:
I det faglige område spiller også udskiftning af Borland Database Engine og Delphi modernisering en vigtig rolle, når integrationer, dataflows og videreudvikling skal fungere problemfrit sammen.
Næste trin
Når et emne bliver til et reelt projekt, bør arkitektur, eksisterende systemer og drift tidligt vurderes samlet.
Vi støtter ikke kun ved enkeltspørsmål, men også når kildekodeudsnit, legacy-komponenter eller portalidéer skal udvikles til et robust virksomhedsprojekt.
- Eksisterende tilstand, målbillede og tekniske risici vurderes samlet.
- REST, dataadgang, portaler og idrulning bliver ikke udskudt som eftertanker.
- I ser tidligt, hvilken vej der er økonomisk og driftsmæssigt holdbar.