Erstat Borland BDE-databaseforbindelsen med native drivere

I mange virksomheder kører Delphi-applikationer, der fagligt er blevet optimeret gennem årene og i dag bærer en væsentlig del af værdiskabelsen. Teknisk er dataadgangen dog ikke sjældent baseret på Borland Database Engine (BDE) – ofte historisk opstået, længe stabil „godt nok“, men i moderne driftsmiljøer stadigt mere problematisk. BDE er udfaset, dens driver- og konfigurationslogik stammer fra en tid før nutidens sikkerheds- og deployment-krav, og koblingen til 32-bit ældre komponenter bliver med hver platformbeslutning mere mærkbar.

BDE-afvikling er derfor ikke en kosmetisk foranstaltning, men et centralt moderniseringstrin: væk fra global alias-konfiguration og legacy-drivere hen imod native databasedrivere og en klar, testbar dataadgang. For virksomheder betyder det: mindre driftsrisiko, reproducerbart deployment, bedre skalerbarhed og et pålideligt fundament for efterfølgende skridt som REST-servere, Windows- eller Linux-services, reporting-workflows og multiplatform-klienter.

Vigtigt er: Skiftet er sjældent „bare udskiftning af komponenter“. Den, der virkelig erstatter BDE, må eftergøre SQL-adfærd, datatyper, tegnsæt, transaktioner, låsemekanismer og fejlbehandling så præcist som muligt – og samtidig udnytte lejligheden til at strukturere dataadgangen decouplet. Netop dér opstår det faglige og økonomiske udbytte: Applikationen bliver ikke blot „igen kørbar“, men vedligeholdelsesvenlig og fremtidssikret.

Hvorfor BDE i dag udgør en risiko

Deployment og konfiguration: globalt, skrøbeligt, svært at automatisere

BDE arbejder typisk med system- eller maskinkonfiguration (BDE Administrator, aliases, centrale parametre). I nutidige miljøer med standardiserede udrulninger, terminalservere, VDI, restriktive rettigheder og automatiserede installationskæder er det en vedvarende kilde til specialtilfælde:

• Afhængighed af globale aliases i stedet for applikationsnær konfiguration (f.eks. per instans, per kunde).
• Konflikter ved parallelle installationer af forskellige applikationer/versioner på samme system.
• Manglende eller vanskelig automatisering i CI/CD og drift (f.eks. reproducerbare setups).

Platform- og fremtidstemaer: 64-bit, ARM64, moderne driver-økosystemer

Mange BDE-scenarier binder applikationer til 32-bit og et forældet driver-økosystem. Selv når en applikation „stadig kører“, bliver handlingsrummet mindre: 64-bit er standard i virksomheds miljøer, og med Windows 11 på ARM64 får spørgsmålet om native afhængigheder yderligere vægt. Moderniseringstrin som en ren 64-bit-migrering eller forberedelse til ARM64 fejler i praksis ofte ikke på grund af Delphi selv, men på grund af forældede driverkæder og installationslogik.

Transaktioner, låsning og flerbrugerbelastning: „fungerer“ vs. „beherskes“

Mange voksede applikationer bruger med BDE en blanding af implicitte transaktioner, auto-commit-adfærd og historisk betingede låseantagelser. Det kan i små brugergrupper være usynligt, men under belastning viser det typiske symptomer:

• Uklare commit/rollback-grænser, især ved flertrinsprocesser.
• Deadlocks eller lange ventetider på låse, fordi låsestrategier ikke passer til målplatformen.
• Fejlbehandling, som ikke oversætter tekniske exceptions til klare faglige tilstande.

Native drivere og moderne dataadgangslag (f.eks. via BDE-afvikling med native tilkobling) giver her betydeligt bedre kontrol: isolerede transaktionsområder, definerede isolation levels, konsistent fejlanalyse og klarere performanceparametre.

Hvad der konkret menes med „native drivere“ i Delphi

„Native drivere“ betyder i virksomhedskontekst: Applikationen taler til mål-databasen via en aktuel, understøttet driverstack, uden mellemlag som BDE og uden globale, konfigurationsafhængige legacy-komponenter. I Delphi er BDE-Ablosung mit nativer Anbindung typisk den teknisk solide standard, fordi det kan adressere forskellige databaser ensartet og samtidig relyere på velafprøvede drivere (afhængig af DB: ODBC/OLE DB/Client-Libs, men kontrolleret og moderne integreret).

Målsætningen er ikke kun „BDE ud, FireDAC ind“, men:

• Et defineret dataadgangslag (layer), der kapsler opsætning af forbindelser, transaktioner og fejlkategorier.
• Konfiguration via applikationsnære indstillinger (fil, secret store, environment), ikke via maskinens tilstand.
• Ren adskillelse af UI, forretningslogik og dataadgang (ofte implementeret som Layer-3 arkitektur).

Typiske udgangssituationer: Hvilke BDE-scenarier vi ser i praksis

Paradox/dBASE i filsystemet

Mange ældre applikationer bruger Paradox-tabeller direkte i et fileshare. Det medfører ud over performance- og låseproblemer især driftsrisici (netværksafbrydelser, filkorruption, backup/restore-kompleksitet). En ren „driverafløsning“ er her ikke tilstrækkelig: Man har som regel brug for en migration til et server-RDBMS (f.eks. MariaDB, PostgreSQL, SQL Server) og dermed et nyt driftsmønster (brugere, roller, backups, monitoring).

BDE mod InterBase/Firebird/Oracle/SQL Server via gamle drivere

Her er databaseserveren ofte allerede „tilstrækkelig moderne“, men adgangen er forældet. I sådanne projekter kan overgangen til FireDAC ofte ske trinvis, fordi datamodellen allerede er relationel. Hovedarbejdet ligger derefter i SQL-dialektforskelle, parameterhåndtering, datatyper og transaktioner.

Blandet drift: BDE plus ekstra grænseflader

I nogle miljøer eksisterer der ud over BDE allerede flere adgangsveje (ADO, ODBC, REST-tilslutninger, import/eksport-komponenter). Det øger risikoen for inkonsistenser: forskellige antagelser om tegnsæt, parallelle låselogikker, dublerede forretningsregler. En BDE-afvikling er derfor også en mulighed for at ensrette adgangsveje og føre de faglige regler tilbage til et centralt sted.

Tekniske faldgruber ved BDE-afvikling – og hvordan man løser dem ordentligt

1) SQL- og dialektforskelle

BDE-SQL og den faktiske SQL-implementering i måldatabasen er ikke identiske. Almindelige emner:

• Dato-literal, strengkonkatenering, funktioner (f.eks. UPPER/LOWER, COALESCE/NVL, SUBSTRING).
• JOIN-syntax og ydre joins (legacy-skriveformer).
• ORDER BY på beregnede kolonner, GROUP BY-regler, DISTINCT-adfærd.

I en kontrolleret modernisering bliver SQL ikke „blindt portet“, men katalogiseret: Hvilke forespørgsler er kritiske (performance, faglige kerneprocesser), hvilke er sjældne, hvilke kan kapsles i views/stored procedures, og hvor betaler et refactoring af forespørgselslogikken sig?

2) Datatyper, null-semantik og feltlængder

BDE har i mange ældre projekter etableret datatypantagelser, som ved native drivere opfører sig anderledes. Typiske konflikter:

• Boolean-felter: 0/1, T/F, Y/N, ægte BOOL-typer – inklusive indeksbrug.
• Fixed vs. variable strings, trimming, padding og sammenligningsadfærd.
• NUMERIC/DECIMAL vs. FLOAT: afrunding, sum-beregning, sammenligningsfejl.
• NULL vs. tom streng: faglig differentiering, valideringer, default-værdier.

En god BDE-afvikling inkluderer derfor altid en datatyp- og konventionsliste. Målet er, at forretningslogik og rapporter ikke „tilfældigt“ afhænger af implicit adfærd, men at reglerne bliver eksplicitte.

3) Tegnsæt, Unicode og sortering (Collation)

Mange ældre Delphi/BDE-applikationer stammer fra ANSI-tider. Senest med Unicode-Delphi og moderne DB-servere skal det være klart:

• Hvilken codepage/collation er aktiv i databasen?
• Hvordan sorteres og sammenlignes umlauter og specialtegn?
• Hvilke felter er teknisk „tekst“, og hvilke er „koder“?

Hvis sortering og sammenligning ikke er afklaret, opstår svært sporbare fejl: duplikerede resultatsæt, inkonsistente søgeresultater, „ens“ værdier der i UI fremstår forskelligt fra i SQL. Native drivere hjælper kun, hvis mål-adfærden er defineret og testet.

4) Transaktionsgrænser og samtidighed

Under BDE blev transaktioner ofte brugt implicit eller håndteret via komponentadfærd. Med FireDAC eller native drivere må (og kan) man være klarere:

• Hvilke faglige processer skal være atomare?
• Hvilke isolation levels giver mening (f.eks. Read Committed vs. Snapshot)?
• Hvordan sikres korrekt cleanup ved fejl (rollback-sikkert)?

Særligt i flerbruger-fachanvendelser er det en gevinst: Man reducerer datainkonsistenser og kan reproducere og analysere låseproblemer.

5) BLOBs, memo-felter og dokumentworkflows

Om tilbud som PDF, e-mails, billeder eller logfiler: BLOB-felter er i ældre applikationer ofte følsomme. Forskellige drivere kan håndtere BLOB-streaming, encoding eller læse-/skrivemodes forskelligt. En robust afvikling undersøger derfor:

• Streaming vs. fuld indlæsning (hukommelsesbehov, performance).
• Grænser og timeouts ved store dokumenter.
• Transaktionsmæssig tilknytning: Hvornår bliver et dokument virkelig „committed“?

Værdemodel: BDE-afvikling uden Big-Bang

I virksomheder er „alt nyt“ sjældent realistisk. Et iterativt forløb, der prioriterer faglig stabilitet og samtidigt forbedrer arkitekturen, er ofte det mest fornuftige.

Trin 1: Statusopgørelse med fokus på risiko og kerneprocesser

Indledningsvis gennemføres en teknisk inventar:

• Hvilke databaser, tabeller, aliases og BDE-konfigurationer findes?
• Hvilke komponenter (TTable/TQuery/TDatabase) anvendes, hvor er SQL „embedded“?
• Hvilke processer er forretningskritiske (afregning, disponering, stamdata vedligehold)?
• Hvilke performance- eller stabilitetsproblemer er kendt?

Resultatet er ikke en akademisk dokumentation, men en robust migrationsrækkefølge.

Trin 2: Definér målarkitektur (dataadgang som eget modul)

For en bæredygtig modernisering bør dataadgangen ikke længere være spredt i forms og reports. Målet er klar kapsling, f.eks. som et datamodul-/service-lag med:

• entydig connection-management,
• central transaktionsstyring,
• ensrettet fejloverførsel (teknisk → fagligt/diagnostisk),
• testbarhed (unit-/integrationstests mod en defineret DB-instans).

I mange Delphi-projekter er det netop dette trin, hvor „legacy-kode“ igen bliver til en vedligeholdelsesvenlig kodebase.

Trin 3: Paralleldrift (Strangler Pattern) i stedet for hård overgang

Praktisk erfaring viser, at det ofte er fornuftigt først at flytte enkelte use-cases: f.eks. læsning af stamdata, derefter skrivning af stamdata, og derefter transaktionskritiske processer. Dermed kan en del af applikationen allerede køre via FireDAC, mens andre områder stadig bruger BDE. Det er afgørende at styre denne overgangsperiode aktivt (ingen dobbelt logik, klare ansvarsfordelinger, definerede accepttest).

Trin 4: Database-side modernisering, hvor det giver faglig gevinst

Med native drivere bliver databasen et mere aktivt systemelement. Det er ikke et mål i sig selv, men ofte fornuftigt:

• Gennemgå indeks og optimér dem i forhold til reelle forespørgsler.
• Tilføj constraints og foreign keys for at sikre datakvalitet.
• Brug views eller stored procedures der, hvor stabilitet og vedligeholdbarhed øges.

Trin 5: Hærde drift og deployment

Den tekniske afvikling er først „færdig“, når drift og udrulning er håndteret:

• Konfigurationsstrategi (per miljø, per kunde) og sikker opbevaring af credentials.
• Logging/tracing for DB-fejl inkl. korrelations-IDs (vigtigt for support og audit).
• Installer-/opdateringsmekanik uden manuel BDE-efterbehandling.

FireDAC som typisk målstack: Hvad virksomheder sætter pris på

FireDAC er i Delphi-projekter ofte det pragmatiske valg, fordi det leverer et moderne dataadgangslag uden at tvinge applikationen ind i et fremmed økosystem. I B2B-fachanvendelser er især følgende punkter relevante:

• Ren connection-håndtering inkl. parametriséring, timeouts og fejlmønstre.
• Transaktioner med klar styring og reproducerbar adfærd.
• Performance-værktøjer (fetch-optioner, batch-updates, prepared statements), der mærkbart forbedrer håndteringen af store datamængder.
• Fleksibilitet i valg af database (f.eks. MariaDB, PostgreSQL, SQL Server), uden at applikationen skal omskrives.

Vigtigt: Selv FireDAC er ikke en „trylleformular“. Gevinsten opstår gennem klare konventioner, konsekvent refactoring af dataadgangsstier og tydelige acceptkriterier.

Mere end drivere: Hvilke moderniseringsmuligheder der åbner sig

REST-servere og services: Eksponér forretningslogik pænt udad

Med kontrolleret dataadgang bliver det væsentligt nemmere at stille eksisterende forretningslogik som REST-API eller køre baggrundsprocesser som services. Mange virksomheder bruger BDE-afviklingen som startpunkt til at:

• opbygge et internt API til andre systemer (ERP, DMS, CRM),
• tilkoble et kundeportal eller partnerportal,
• flytte import-/eksport-workflows og tidsstyrede opgaver til services.

Det fælles grundlag er altid det samme: Uden robust, native dataadgang bliver enhver API-/service-lag et risikomoment, fordi forbindelser, transaktioner og fejlscenarier ikke kan styres pålideligt.

Multiplatform og nye målplatforme (inkl. Windows 11 ARM64)

Virksomheder planlægger i stigende grad heterogene klientlandskaber: klassiske Windows-desktops, virtuelle miljøer, enkelte macOS-arbejdspladser, og flere ARM64-enheder. En BDE-bundet applikation er her strukturelt begrænset. Med native drivere og et moderne dataadgangslag øges sandsynligheden for, at platformsvalg ikke fejler på dataadgangen.

Arkitekturdisciplin: Væk fra databasenær UI-logik

BDE-applikationer er historisk ofte bygget tæt på databasen: UI-komponenter binder direkte på TTable/TQuery, forretningsregler er spredt, og dataadgang udføres „ved siden af“. Overgangen giver mulighed for at rydde op:

• Samle forretningslogik i services/klasser,
• afbinde UI,
• skabe validerbare use-cases,
• håndtere fejl og specialtilfælde konsekvent.

Det er ikke akademisk: Det reducerer supportomkostninger og gør ændringer mere forudsigelige.

Kvalitetssikring: Hvordan man sikrer, at „samme resultat“ virkelig er det samme

En BDE-afvikling fejler sjældent ved forbindelsesopbygningen, men ved faglige kanttilfælde. Derfor kræves en QA-strategi, der går ud over „det ser rigtigt ud“:

• Golden-Master-tests for centrale lister/reports (samme input → samme output).
• Transaktions-tests for kritiske bogføringer/statusskift (provocer fejl, verificér rollback).
• Load- og samtidighedstests på de reelt kritiske tabeller og indeks.
• Migrationstests for tegnsæt/collation, især ved søgning, sortering og dubletlogik.

For virksomheder er det forskellen mellem „teknisk omlagt“ og „driftsstabilt moderniseret“.

Kost-/nytte-perspektiv: Hvor ROI for en BDE-afvikling ligger

Indsatsen ved en BDE-afvikling afhænger stærkt af udgangssituationen (Paradox vs. server-DB, SQL-andel, arkitekturtilstand). Gevinsterne kan dog ofte formuleres i tilbagevendende mønstre:

• Reducerede driftsrisici: færre afhængigheder, mindre manuel konfiguration, færre „mystiske“ runtime-fejl.
• Hurtigere ændringer: SQL- og dataadgangslogik er centraliseret, testbar og sporbar.
• Bedre skalerbarhed: målrettet performance-optimering, kontrollerede transaktioner, planlagt låsehåndtering.
• Forberedelse til næste skridt: REST-server, services, portal-tilkobling, 64-Bit/ARM64, multiplatform.

I B2B-fachanvendelser er den væsentligste effekt sjældent „et par procent hurtigere“, men et mere stabilt, kalkulerbart driftmiljø og en markant lavere barriere for yderligere modernisering.

Konklusion: At erstatte BDE betyder at genvinde kontrol over dataadgangen

Borland BDE var historisk en praktisk bro mellem Delphi og databaser. I moderne virksomheds miljøer er den dog en flaskehals: teknisk udfaset, deployment-intensiv, svær at automatisere og i mange tilfælde inkompatibel med aktuelle platformmål. En veludført BDE-afvikling med native drivere – ofte via FireDAC – er derfor et strategisk skridt, der rækker langt ud over „biblioteksskift“.

Den, der sætter omlægningen op som et kontrolleret moderniseringsprojekt, vinder ikke blot stabilitet og bedre transaktionskontrol, men også en arkitektur, der bærer REST-servere, services og efterfølgende moderniseringstrin. Afgørende er en grundig statusopgørelse, en klar målarkitektur, trinvis migration og en QA, der beviser faglig lighed.

Hvis I vil planlægge afviklingen struktureret og undgå unødvendig Big-Bang, er et fornuftigt første skridt en fælles gennemgang af den aktuelle situation og en solid migrations-roadmap: https://net-base-software-gmbh.de/kontakt/