Fra magasinets tema til projektpraksis
Passende service- og tekniske sider til artiklen
En BDE-udskiftning står ikke øverst på ønskelisten i mange virksomheder – men ender før eller siden på risikokortet. Borland Database Engine (BDE) er en historisk dataadgangs-stack 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 kører“, virker emnet håndterligt. I praksis er det dog som regel drift, opdateringer og grænseflader, der svigter først: overgang til 64-bit, nye Windows-versioner, moderne databaser, sikkerhedskrav, Terminalserver/VDI eller blot ønsket om stabil og sporbar administration.
Denne artikel placerer problemet i perspektiv: hvor en BDE-baseret applikation realistisk kan fejle i dag, hvordan du planlægger udskiftningen, så data, grænseflader og processer fortsætter uden afbrydelser, og hvilke migrationsveje der har vist sig pålidelige i praksis. Fokus er ikke „kode-kosmetik“, men driftsikkerhed, datakvalitet, vedligeholdbarhed og muligheden for gradvis modernisering af applikationen – uden unødvendigt Big-Bang.
Hvorfor BDE bliver et problem i drift
BDE er ikke kun „gammel“, men matcher på flere niveauer ikke længere moderne IT-standarder. Det viser sig sjældent som et enkelt stort sammenbrud, men gennem mange små friktionstab, der koster IT-teamet tid og øger risikoen.
Tekniske og organisatoriske symptomer
- Ustabile eller svære at vedligeholde klientinstallationer: BDE-konfiguration, alias-håndtering, stier, skriveadgange og afhængigheder er ofte ikke nemme at pakke korrekt. I Terminalserver- eller VDI-opsætninger eskalerer disse problemstillinger hurtigt.
- Driver- og kompatibilitetsgrænser: Moderne databaser og sikkerhedskonfigurationer (f.eks. TLS-standarder, autentificeringsmetoder) kan ikke længere robust understøttes via BDE-forbindelser.
- 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 dermed en flaskehals.
- Sikkerhed og hardening: Gamle datastier, lokale filer, uklare rettighedskrav og manglende krypterings- eller auditfunktioner passer dårligt til nutidens sikkerheds- og compliance-krav.
- Manglende fremtidssikring af grænseflader: Når APIs (REST), central identity (f.eks. SAML 2.0 som standard for Single Sign-on) eller servicebaseret integration kræves, virker en BDE-kerne som et anker på legacy-klienten.
Væsentligt: En BDE-udskiftning er sjældent „kun“ udskiftning af en bibliotekskomponent. Den berører datamodeller, transaktioner, locking (låseadfærd), samtidighed, fejlbehandling, deploys og ofte også rettighedsmodellen.
BDE-udskiftning realistisk indplaceret: Hvad bliver der konkret erstattet?
I bestående applikationer er „BDE“ som regel en samlebetegnelse. For en robust planlægning skal det være klart, hvilke roller BDE spiller i det konkrete system:
- Dataadgangslag: Datasets, Queries, Stored Procedure-kald, cursor-adfærd, parameterbinding.
- Driver-/tilslutningslag: Tilslutning til Paradox, dBASE, InterBase/Firebird eller også SQL Server/Oracle via ældre driverstier.
- Konfiguration: BDE-Administrator, Aliases, NetDir, lokale stier, fælles mapper.
- Semantik: Hvordan håndteres låsning? Hvordan fortolkes dato-/talformater? Hvilke felttyper og indekser er historisk brugt?
For IT-ledelse og administration er denne afklaring forskellen mellem „lille opdatering“ og et struktureret moderniseringsprojekt. Først derefter kan man afgøre, om en ren modernisering af dataadgangen er tilstrækkelig, eller om samtidig en databasemigration eller arkitekturhygiejne er hensigtsmæssig.
Målarkitekturer efter BDE: typiske veje
Der findes ikke én erstatning. I praksis har tre veje etableret sig, som også kan kombineres:
1) Direkte skift til FireDAC med eksisterende database
BDE-afvikling med native tilslutning er et moderne dataadgangsbibliotek for Delphi, som understøtter forskellige databaser og drivere og i dagligdagen er klart nemmere at automatisere end BDE-konfigurationer. Denne vej egner sig, hvis databasen i sig selv er holdbar, 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) omhyggeligt.
2) Migration fra Paradox/filbaseret til klient-server (PostgreSQL, SQL Server, MariaDB)
Hvis der stadig anvendes Paradox-tabeller eller andre filbaserede strukturer, er BDE-afviklingen ofte det rigtige tidspunkt til at gå til en central database. Klient-server betyder her: transaktioner sikres på serversiden, backups kan styres centralt, rettigheder kan defineres på DB-niveau, og samtidige adgang kan håndteres mere kontrolleret. For drift og sikkerhed er det som regel den største effekt.
3) Afkobling via tjenester: REST-API foran bestandslogikken
I stedet for at ombygge klienten fuldstændigt med det samme, kan en REST-service (REST står for „Representational State Transfer“, en udbredt stil for HTTP-baserede grænseflader) fungere som et integrationslag. Derved kan portaler, eksterne systemer eller nye moduler tilsluttes, uden at hver adgang kommer direkte fra legacy-klienten. Denne vej er særligt nyttig, hvis applikationen skal vokse trinvis mod en modulær arkitektur.
Forarbejde, der afgør succes eller stilstand
En BDE-afvikling fejler sjældent på den tekniske mulighed, men på manglende gennemsigtighed 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, hvor ligger de i dag?
- Transaktionsgrænser: Hvor forventer forretningsprocessen „alt eller intet“? Hvor har man hidtil levet med delvise opdateringer?
- Batch- og hjælpeprocesser: Import/Export, rapportering, PDF-udtræk, natlige kørsler, integrationsjobs. Disse dele er ved migrationer ofte de egentlige fejlkilder.
- Driftsbillede: Hvordan deployes der (MSI, Copy-Deploy, softwaredistribution)? Hvilke rettigheder kræves på klienterne? Hvilke logfiler findes? Hvordan varetages support?
Til denne fase er det værd bevidst at inddrage administrationsviden: „Hvad sker der ved en klientudskiftning?“, „Hvordan reagerer vi på beskadigede data?“, „Hvor lang tid tager en gendannelse?“ – det er de spørgsmål, der senere afgør udrulningen.
Dør datakvalitet og implicitte regler synlige
Især ved Paradox- eller historisk opståede datamodeller er mange regler implicitte: værdigrænser, specialkoder, „tomme“ felter som betydningsbærere eller referencer uden egentlige fremmednøgler. Ved en migration til PostgreSQL/SQL Server/MariaDB skal der træffes beslutning om, hvilke regler der fremover skal håndhæves teknisk (Constraints), og hvilke der indledningsvis kun skal valideres (f.eks. via kontroljobs). Denne beslutning er ikke akademisk: For stramme regler kan blokere en produktionsimport, for løse regler bevarer fejl på længere sigt.
Tekniske kernespørgsmål ved BDE-udskiftning
For beslutningstagere fremstår „udskiftning af dataadgang“ ofte ligetil. I praksis er der dog flere tekniske indstillingsmuligheder, der direkte påvirker drift, stabilitet og supportindsats.
Datatyper, Unicode og sortering
Mange legacy-applikationer bærer byrder fra ANSI-tiden. Ved en modernisering skal tegnsæt, sorteringsrækkefølger (Collation), store/små bogstaver og specialtegn (umlauter, ß) defineres entydigt. Ellers opstår „spøgelsesfejl“: søgninger giver andre resultater, dubletter opstår, 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 klient-server. I SQL-databaser bestemmer isolationsniveauer, Row Locks og deadlock-håndtering samtidighed. For driften betyder det: Man skal vide, hvilke operationer kører længe, hvilke tabeller er „hotspots“, og hvor man kan arbejde med passende indekser, kortere transaktioner eller optimerede forespørgsler. Her betaler et solidt monitoring sig, i stedet for blot „det føles langsomt“.
Fejlbilleder: Fra klientdialog til kontrolleret logging
Mange ældre applikationer rapporterer databasefejl direkte via dialog eller skriver utilstrækkeligt anvendelige meddelelser. Efter BDE-udskiftningen bør fejl være centralt eftersporelige: hvilken Query, hvilken bruger, hvilken handling, hvilken databasemeddelelse? For administrationen er det afgørende, at fejl kan afgrænses reproducerbart uden at skulle lave lokale rettelser på enkelte klienter. I servicebaserede dele tilføjes strukturerede logs (f.eks. JSON) og korrelations-ID’er for at spore Requests på tværs af flere komponenter.
Deployment og konfiguration: væk fra Alias-Wildwuchs
Et hyppigt 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-poster, som sættes via softwaredistribution. For terminalservere er det særligt vigtigt. Også certifikater, TLS-parametre og proxy-emner bør ikke vedligeholdes „manuelt“.
Migrationsstrategi: Trinvist i stedet for Big Bang
En udskiftning kan ske i etaper. Det reducerer nedetidsrisiko og tillader tidlige forbedringer i driften, mens applikationen fortsat anvendes.
Etape 1: Stabil dataadgang som udskifteligt lag
I mange Delphi-applikationer er dataadgangen fordelt på tværs af UI’en. Et praktisk mellemtrin 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 vedligeholdelse: Når alle DB-adgange samles på få steder, kan drivere, parametre og transaktionshåndtering ændres konsekvent.
Etape 2: Parallelkørsel og sammenligningstests
Etape 3: Cutover med tilbagefaldsstrategi
Skiftetidspunktet (Cutover) bør planlægges praktisk: vedligeholdelsesvindue, datafreeze, definerede tjeklister, overvågning og et klart „Rollback“-scenario. Rollback betyder ikke, at man skifter frem og tilbage vilkårligt, men at man i tilfælde af problemer ordnet kan genoptage driften. Det omfatter backups, RESTore-øvelser og en plan for, hvordan man sikrer datakonsistens efter et tilbagefald.
Database-migration i detaljen: hvad IT og drift bør være opmærksomme på
Når man i forbindelse med en BDE-udskiftning migrerer fra Paradox eller andre filbaserede strukturer til en central SQL-database, står IT-teams over for flere beslutninger, der senere vil præge driftsomkostninger og support.
Skema-design: 1:1 overtage eller målrettet forbedre?
En 1:1-overntagelse reducerer kortsigtet risiko, men bevarer ofte svagheder: manglende primærnøgler, inkonsistente datatyper, „semantik i strenge“, historisk opståede feltlængder. En realistisk fremgangsmåde er todelt: først stabilt migrere (minimale ændringer), derefter konsolidere i kontrollerede trin. Det kræver versionering af skemaet (migrationer), så ændringer kan rulles ud sporbart.
Performance: Indekser og typiske forespørgsler bør vurderes tidligt
Paradox- og BDE-typiske adgangsmønstre passer sjældent 1:1 til SQL. Det er afgørende tidligt at måle de vigtigste use-cases: søgeformularer, lister, posteringer, batchkørsler. Heraf følger indekser, query-optimeringer og eventuelt materialiseringer. For driften er det vigtigt, at ydeevne ikke opstår „tilfældigt“, men via måledata og efterprøvbare tiltag.
Backup/RESTore og høj tilgængelighed
Med en central database ændrer spillereglerne sig: Backups skal være konsistente, regelmæssigt kontrolleres og hurtigt gendannes. RESTore-tests er ingen luksus, men grundlaget for robuste RTO/RPO-mål (RTO = tid til genoprettelse, RPO = maksimalt datatab i tid). Afhængigt af kritikaliteten kommer replikation, standby-instanser eller klart regulerede vedligeholdelsesvinduer på tale. En BDE-udskiftning er et godt tidspunkt til endeligt at definere disse driftskrav ordentligt.
Grænseflader og integration: den ofte undervurderede del
Mange eksisterende applikationer lever ikke isoleret. De forsyner et DMS, er koblet til ERP, leverer data til BI/rapportering eller kommunikerer med maskiner/værktøjer. Ved en BDE-udskiftning ændrer grænseflader sig sjældent fagligt, men teknisk.
Stabiliser import/export
Typiske fejlårsager er faste stier, lokale drev, Excel-formater, CSV-encoding og manglende validering. Ved en modernisering er det værd 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 kobles på, er en REST-API ofte den pragmatiske vej. Vigtigt er ikke kun endpoints, men driftsaspekter: autentificering (f.eks. token), rate limits, logging, 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 udfasning
Med afslutningen af BDE opstår muligheden for at gøre rettigheder mere konsistente. Ofte er rettigheder i legacy-systemer delvist indbygget i applikationen, delvist „gennem filstier“. Moderne målbilleder adskiller klart:
- Autentificering: Hvem er brugeren? (f.eks. Windows/AD, SSO via SAML 2.0)
- Autorisering: Hvad må brugeren i applikationen? (roller, rettigheder, tenants)
- Database-rettigheder: Applikationens adgang sker via tekniske DB-brugere, ikke via slutbruger-konti; følsomme admin-operationer er adskilt.
- Audit og sporbarhed: Væsentlige ændringer bør kunne protokolleres (hvem, hvad, hvornår), uden at alle detaljer forsvinder i logfilerne.
For IT-ledelsen er det relevant: Sikkerhed opstår ikke gennem „flere dialoger“, men gennem klare ansvarsfordelinger og verificerbare regler. Netop dette muliggøres ofte for første gang gennem en struktureret BDE-udfasning.
Test- og udrulningsplan: hvad der i praksis virkelig tæller
Ved moderniseringer er testbarhed et driftskriterium. Jo mindre reproducerbart, jo højere bliver supportomkostningerne. En pragmatisk udrulningsplan kombinerer tekniske og organisatoriske tiltag.
Testtyper, som I bør planlægge
- Regressionstests af kerneprocesser: bogføringer, stamdata, søgning, rapporter, udskrift/PDF.
- Datavalidering: stikprøver og automatiserede checks (antal, summer, referencer, dubletter).
- Load-/performance-checks: ikke som „benchmark“, men i forhold til reelle spidsbelastninger og batchkørsler.
- Driftstests: installation, opdatering, rollback, logrotation, backup/restore, monitoring-hændelser.
Pilotering og trinvist udrulning
En pilot med klart afgrænsede brugergrupper og definerede supportveje reducerer risikoen. Det er vigtigt at indsamle feedback struktureret: Hvilke fejl er reelle defekter, hvilke er adfærdsændringer pga. sortering/Unicode, hvilke er processpørgsmål? En ordentlig ticket- og prioriteringsproces forhindrer, at projektet sætter sig fast i „alt er lige vigtigt“-modus.
Hvornår er en BDE-udfasning særligt fordelagtig – 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 client-setup, stier, rettigheder eller terminalserver-miljøer
- Behov for central datalagring, ordentligt backup/restore og sporbare audits
- Nye krav til grænseflader (portaler, BI, eksterne partnere) og sikkerhed
Nogle gange er BDE-udfasning dog kun det første skridt: Hvis UI/UX, proceslogik eller rettighedsmodel samtidigt skal fornyes grundlæggende, bør projektet planlægges modulært. „Alt på én gang“ kan virke effektivt, men fører i mange virksomheder til lange freeze-faser og vanskeligt testbare mellemtilstande. Bedre er en roadmap, der tidligt synliggør driftsfordele: stabil adgang til data, central database, bedre logs, og derefter trinvis yderligere modernisering (f.eks. portaler eller services).
Konklusion: BDE-udfasning som en kontrolleret moderniseringssti
En BDE-udfasning er mere end et rent teknisk refaktorering. Rigtigt planlagt er det et kontrolleret skridt mod mere driftbar forretningssoftware: standardiserede Deployments, efterprøvbar datalagring, klarere grænseflader, forbedret sikkerheds- og audit-kapacitet samt muligheden for at tilkoble moderne arkitekturkomponenter som REST-Services eller portaler. Nøglen er en pålidelig kortlægning af det eksisterende, en trinvis migrationsstrategi og et rollout, der tager drift og datakvalitet lige så alvorligt som funktionalitet.
Hvis du vil vurdere din udfasning struktureret og fastlægge en realistisk migrationsvej, så kontakt os:
I det faglige regi spiller også udskiftning af Borland Database Engine og Delphi modernisering en vigtig rolle, når integrationer, dataflows og videreudvikling skal spille sammen på en ryddelig måde.
Næste trin
Når emnet 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 udrulning bliver ikke udskudt som efterfølgende opgaver.
- De ser tidligt, hvilken vej der er økonomisk og driftsmæssigt bæredygtig.