Udskift Borland BDE med FireDAC: Afvejningsoverblik for sikker migration

Mandag morgen, kl. 08:15. En nyligt udrullet Windows-opdatering, en ny Endpoint-beskyttelse, derudover et „lille“ pakke fra softwaredistributionen – og pludselig står en lokation stille. En forretningskritisk Delphi-applikation starter vist nok, men ved første dataadgang fremkommer „Alias ikke fundet“ eller „Netværkssti ugyldig“. I ticketforløbet dukker begreber op, som i mange IT-teams længe ikke længere har en fast plads: BDE-administrator, NetDir, lokale konfigurationsfiler, der ligger „et eller andet sted“ og virker „på en eller anden måde“.

Den, der vil erstatte Borland BDE med BDE-Abløsning med native tilslutning, har som regel ikke luksusproblemet „vi moderniserer for sjov“, men en reel målsætningskonflikt. Mål 1: maksimal stabilitet i daglig drift, ingen overraskelser i bogføringskørsler, rapporter eller grænseflader. Mål 2: at løfte applikationen ud af legacy-specialtilfældet – væk fra skrøbelig client-konfiguration og hen mod en dataadgang, der passer til 64‑Bit, Unicode, Security-Baselines og en ren databasestrategi. Dette vurderingskort placerer nytte, indsats, risici og begrænsninger og viser, for hvem hvilken beslutning er plausibel.

Målsætningskonflikt som udgangspunkt: Forblive stabil eller købe fremtiden?

Mål A: Stabilitet, fordi processen afhænger af det

Mange BDE-baserede applikationer er operationelt „indspillet“. Support kender særhederne, forretningsområder er vant til bestemte skærmforløb og lister, og selv ujævnheder er indregnet. Netop derfor er en ændring af dataadgangen risikabel: Fejl viser sig ofte ikke som et crash, men som en stille afvigelse – en anderledes sortering, en anden afrunding, en anden håndtering af NULL-værdier, en uventet lang låsning. For IT-ledelse og drift betyder det: Migration er kun forsvarlig, når ensartet resultat og rollback er realistisk sikret.

Mål B: Fremtidssikring, fordi drift og platform ikke står stille

Samtidig er Borland Database Engine (BDE) ikke „kun gammel“, men officielt udfaset (deprecated). Embarcadero påpeger eksplicit, at BDE ikke længere vil blive videreudviklet og for eksempel aldrig vil få Unicode-understøttelse; for eksisterende applikationer anbefales en migration til BDE-Ablosung mit nativer Anbindung.^[Quelle] Praktisk konsekvens: Jo mere konsekvent I hærdet klienter, distribuerer software, begrænser rettigheder og ensarter platforme, desto mindre passer en dataadgang, der afhænger af historiske globale indstillinger og en forældet driververden. Det vedrører ikke kun „IT-æstetik“, men også incident-risiko og planlægning.

Hvad der reelt ændrer sig, når I erstatter Borland BDE med FireDAC

I mange projektplaner står der i praksis: TDatabase bliver TFDConnection, TQuery bliver TFDQuery, TTable bliver TFDTable. Det er den synlige del. Den relevante del ligger under overfladen: BDE har gennem årene båret implicitte antagelser (konverteringer, standard-sorteringer, transaktionsbivirkninger, konfigurationssteder). FireDAC er som regel strengere, mere transparent og tættere på den konkrete database. Det forbedrer vedligeholdelse og diagnostik – men tvinger til at nedfælde antagelserne og teste dem.

Fire forskelle, der gør sig gældende i drift og fagafdelingen

• Konfiguration og deployment: BDE-setups har historisk arbejdet med globale Alias-/NetDir-konfigurationer og filer, der kan variere pr. maskine eller pr. profil. FireDAC kan konfigureres tæt på forbindelsen og styres bedre pr. miljø, men kræver afhængigt af databasen passende clientbiblioteker og en klar opdaterings- og distributionsstrategi.
• Datatyper, parametre, implicit konvertering: FireDAC er ofte mere præcis. SQL, der „tilfældigvis“ virkede (dato som streng, tal som tekst), træder tydeligere frem. Det er godt – forudsat at I ser fejlene i testene, ikke ved månedsafslutningen.
• Unicode og collation (sortering/tegnsætsregler): Hvis applikationen historisk bruger ANSI-logik, kan en modernisering synliggøre tegn- og sammenligningsproblemer: sortering, store/små bogstaver, umlauter, eksportformater. Det kan løses, men er ikke automatisk „identisk“.
• Transaktioner og låseadfærd: Mange legacy-mønstre er afhængige af dataset-drevne sideeffekter. FireDAC tilbyder ren transaktionsstyring – men kræver, at I fastlægger, hvor transaktioner begynder og slutter.

Afvejningstabel: Fordele, indsats, risici og begrænsninger

Wann die Migration besonders plausibel ist

Wenn Deployment und Security-Härtung regelmäßig kollidieren

Jo mere standardiseret jeres Client-Landschaft er (Softwareverteilung, begrænsede rettigheder, segmenterede netværk, Endpoint-Schutz), desto mere fremhæves alt, der konfigureres ‚per Maschine‘ eller ‚per Nutzerprofil‘ og i fejltilfælde kun kan repareres ved manuel reproduktion. FireDAC tvinger jer ikke automatisk til et godt konfigurationsmodel, men det passer bedre til en tilgang, hvor forbindelsesparametre pr. miljø defineres, versioneres og dokumenteres.

Wenn 64‑Bit-Planung oder neue Hardware ansteht

Mange virksomheder skifter ikke på grund af en IDE‑version, men fordi terminalservere fornyes, nye operativsystemudgaver rulles ud eller sikkerhedspolitikker skærpes. Så bliver dataadgang et kritisk afhængighedspunkt. Den, der moderniserer den, afkobler efterfølgende projekter: Det næste platform- eller infrastrukturoverhoved behøver ikke samtidig at løse dataadgangsproblemet.

Wenn Datenhaltung ohnehin „erwachsen“ werden soll

I filbaserede scenarier (klassisk Paradox/dBase) er den største risiko sjældent UI’en. Det er locking, backup-realitet, dataintegritet, rettigheder og flerbrugerdrift. FireDAC er primært lavet til SQL-databaser og klare transaktionsmodeller. Hvis en serverbaseret database-strategi alligevel er på bordet, er den BDE-udskiftning ofte tidspunktet til at planlægge begge dele sammen – med alle konsekvenser for drift (Backups, Monitoring, Wartungsfenster, Rollen-/Rechtekonzept).

Drei Migrationspfade – mit sehr unterschiedlichem Risiko-Profil

Pfad 1: Mechanisch „wieder kompilieren“ (nur als Zwischenziel)

Embarcadero beskriver i Upgrade/Migration Center en typisk FireDAC-migration som en flertrinsproces og nævner også ‚reFind‘ som et værktøj, der hjælper med den mekaniske del: erstatte komponenter, opdatere uses-klausuler, foretage grundlæggende ændringer for at kunne kompilere igen.^[Quelle] Som mellemliggende status er det nyttigt. Som afslutning er det for lidt, fordi kompilering ikke siger noget om faglig resultatlighed, Performance under Last eller Concurrency.

Pfad 2: Datenzugriff kapseln, dann umstellen (häufig der beste Kompromiss)

I stedet for at ombygge hver enkelt formular direkte, flyt datapågangen til få ansvarlige steder: Connection-oprettelse, central fejlhåndtering, Logging/Tracing, bindende parameter- og transaktionsregler. Derefter migrerer I modulvis. Det reducerer migrationsfladen og gør godkendelse og drift mere planlægnelige, fordi adfærden kan observeres og korrigeres ét sted.

Vej 3: FireDAC + databaseudskiftning (stor gevinst, men højere krav til governance)

Hvis der alligevel er et spring fra filbaseret til serverbaseret, kan det være effektivt at kombinere begge dele. Gevinsten er stor (transaktioner, rettigheder, monitoring, bedre driftsprocesser). Prisen er, at I skal beslutte mere end „teknik“: datamigrering, skemadesign, cutover, paralleldrift, tilbagefaldsstrategi. Uden et klart godkendelsesformat og driftsaftaler bliver denne vej hurtigt et langvarigt projekt.

Et praksisegnet forløb i 7 trin (uden Big Bang)

1. Inventar som risikokort: Hvilke datakilder, hvilke adgangsformer (TTable-tunge vs. SQL), hvilke kritiske rapporter, hvilke batchkørsler, hvilke import-/eksportgrænseflader afhænger af datasetadfærden?
2. Vælg måltilstand: „FireDAC på samme database“ eller „FireDAC plus databasemodernisering“. Det er en portefølje- og driftsbeslutning, ikke et rent udviklerspørgsmål.
3. Definér fundament: Central Connection-konfiguration, timeouts, fejlhåndtering, valgfrit skiftbart Tracing/Logging. Mål: reproducerbart i Dev/Test/Prod.
4. Vælg pilotproces: Ikke den mindste formular, men en fagligt klart afgrænset proces med læs og skriv (transaktioner, låsning, validering) og klare godkendelseskriterier.
5. Påvis resultatlighed: Sammenligning af Resultsets, rapporter og centrale nøgletal på definerede testdata. Fokus: NULL, datumslogik, afrundinger, tegnsæt, sortering.
6. Migration i bølger: Efter moduler/Use Cases, med release-ring (pilotgruppe, supportvindue, rollback-pakke, kommunikation). Paralleldrift er tilladt, men teknisk klart adskilt.
7. Fjern BDE fra deployment: Fjern installer, dokumentation og konfigurationsRESTer. Så længe BDE „for en sikkerheds skyld“ er medinstalleret, består også en del af driftsrisikoen.

Typiske risikozoner – og hvordan man får dem administrativt under kontrol

1) Datatyper, NULL og „historiske“ konverteringer

Mange ældre Delphi-applikationer indeholder grænsetilfælde, som længe ikke er blevet rørt: tomme strenge i stedet for NULL, tal i tekstfelter, dato som streng, „0“ som falsk. FireDAC ødelægger ikke sådanne steder automatisk, men gør dem mere synlige. For drift og fagafdeling er det en fordel, fordi fejl bliver mere reproducerbare – hvis De fastlægger regler: Hvilke kolonner må være NULL? Hvilke standardværdier gælder fagligt? Hvordan gemmes boolske værdier? Hvilken tidsopløsning er relevant (dato vs. Timestamp)?

2) Transaktioner, locks og samtidighed

I BDE-arkitekturer opstår transaktioner ofte „ved siden af“: datasæt åbnes, brugeren klikker, på et tidspunkt postes der. På serverbaserede databaser kan det føre til lange transaktioner og unødvendige låsninger. Ved en FireDAC-migration er en enkel tommelfingerregel nyttig: transaktioner bør placeres omkring use-caset, ikke omkring UI’en. Det kan betyde, at gemme-operationer grupperes, valideringer forrykkes frem og fejlbehandling centraliseres.

3) SQL-dialekt, reserverede ord, deterministisk sortering

En del af arbejdet er ikke „FireDAC“, men SQL-hygiejne. BDE har historisk tolereret en del: uklare aliasnavne, implicitte joins, ikke-deterministisk sortering. FireDAC er her ikke modstanderen, men forstærkeren: problemerne bliver synlige. Den robuste løsning er næsten altid at gøre SQL eksplicit. Det hjælper også administratorer, fordi forespørgsler derved bliver lettere at analysere (indexbehov, udførelsesplaner, belastningstests).

4) Reporting, eksporter, revisionsrelevante udtræk

Hvis rapporter bruges til månedsafslutning, afregning eller revisionsrelevante udtræk, er „stille“ afvigelser den reelle risiko. Behandle kritiske rapporter derfor som egne produktkomponenter: definerede testdata, forventede summer/rækkeantal, dokumenteret filterlogik, godkendelse fra fagafdelingen. Hvor det er muligt, stabiliser datagrundlaget (f.eks. via klart definerede queries eller views) i stedet for at acceptere UI-side filtreringskæder som sandhed.

Arkitekturkonsekvenser: Hvad FireDAC muliggør – og hvad ikke opstår automatisk

God basis for services, jobs og grænseflader

Mange virksomheder udvider desktop-systemer med REST-services, baggrundsbehandling eller portaler. En moderne dataadgang passer til det, når Connection-Lifecycle, fejlbehandling og transaktioner er ordentligt indkapslet. Uden denne indkapsling opstår blot „en ny driver i gammel struktur“ – og hvert efterfølgende projekt opbygger igen sine egne regler.

FireDAC erstatter ikke afkobling mellem UI og forretningslogik

Hvis formularer i dag sammensætter SQL, forretningsregler ligger i eventhandlere og globale tilstande dominerer, forbliver det sådan umiddelbart efter migrationen. FireDAC er ikke et arkitekturtiltag, men en god anledning til at indføre en minimal struktur: central forbindelseshåndtering, få adgangsklasser per fagligt modul, definerede fejl- og transaktionsregler. Det er ofte nok til at gøre vedligehold og drift betydeligt mere forudsigelige.

Grænser og særlige tilfælde, som De bør tage op tidligt

Systemer stærkt drevet af TTable/Paradox

Hvis beholdningen er stærkt filbaseret, er det egentlige spørgsmål ikke „BDE eller FireDAC“, men „hvilken dataopbevaring“. FireDAC er ikke beregnet til at bevare en filbaseret verden uændret. Den, som skal modernisere Paradox-data, bør planlægge indsatsen for datamigration, skemadesign, rettigheder, backup/RESTore-tests og cutover omhyggeligt – inklusive parallelkørsel og dataafstemning, hvis et hårdt skifte fagligt ikke er muligt.

Parallelkørsel er et værktøj, ikke en sluttilstand

Ja, BDE og FireDAC kan køre parallelt. Prisen er kompleksitet: dobbelt konfiguration, dobbelte fejlbilleder, flere afhængigheder. Sæt derfor tidligt en slutdato for BDE-nedbygningen og definer adskillelseslinjen (Module, Use Cases, tekniske lag). Halvt‑halvt uden et målbillede bliver i drift som regel dyrere end en beslutsom ombygning i bølger.

Hvilke beslutninger IT-ledelse og drift tidligt bør fastlægge

• Umgebungsstrategie: Hvordan administrerer I Dev/Test/Prod-konfigurationer? Hvem må ændre Connection-Parameter? Hvordan håndterer I Secrets?
• Treiber- und Updatepolitik: Hvordan versioneres og distribueres Client-Libraries? Findes der release-ringe og en fallback-mulighed?
• Beobachtbarkeit: Hvilke logs har driften brug for ved en incident? Hvilke SQL-kontekster må logges af hensyn til databeskyttelse eller beskyttelsesbehov?
• Abnahmeformat: Hvilke kerneprocesser skal være dækket som regressionstest (Lister, Buchungen, Exporte, Reports)?
• Rollback-Plan: Hvad er tilbagefaldsstrategien pr. bølge – teknisk (Pakete), organisatorisk (Kommunikation) og datarelateret (kein Datenverlust)?

Det afgørende løft: Tillid gennem påvisning

De fleste migrationer fejler ikke på „tilslutningen“, men på tilliden. Tillid opstår, når I kan vise, at kritiske processer fagligt forbliver identiske – eller når afvigelser er bevidst besluttet og klart kommunikeret. Netop her ligger chancen ved omstilling: Den tvinger til eksplicitte regler (Sortierung, Datentypen, Transaktionen) og skaber dermed et grundlag, som også om to år stadig er vedligeholdelses- og driftsmæssigt håndterbart. FireDAC er så ikke målet, men midlet til at bringe drift og videreudvikling tilbage i en planlægningsbar normaltilstand.

Hvis I ønsker at forberede udskiftningen struktureret (Risikokarte, Pilot, Test- und Rollout-Plan), kan I sætte projektet i gang her: Projekt eller moderniseringsprojekt med Net-Base besprechen.

For dette emne er også Delphi Modernisering og FireDAC migration vigtige. Indlægget sætter disse aspekter i perspektiv og viser, hvad der betyder noget i praksis.

Drøft projekt eller moderniseringsforløb med Net-Base.