Delphi Virksomhedsapplikationer: Hvorfor mange systemer kører stabilt – og hvordan I kan gøre dem fremtidssikre

I mange virksomheder kører Delphi Unternehmensanwendungen pålideligt i årevis: produktionstilnærmede registreringer, disposition, lager, forsendelse, service, kvalitetssikring eller administrative kerneprocesser. Sådanne systemer er sjældent „pæne“, men de er ofte særdeles værdifulde – fordi de afbilder processer, som ikke lader sig presse ind i standardsoftware. Netop derfor er Delphi i praksis fortsat relevant: ikke som en trend, men som et stabilt fundament for individuel virksomhedsoftware, der er opstået under tidspres og siden er vokset over år.

For IT-ledelse og administration er spørgsmålet mindre „Delphi: ja oder nein?“, og mere: Hvordan holder jeg systemet driftssikkert, sikkert og ændringsvenligt, uden at blokere organisationen med et Big-Bang-nybyggeri? Dette indlæg kategoriserer typiske Delphi-landskaber og viser praksisnære moderniseringsveje – med fokus på drift, data, grænseflader, vedligeholdbarhed, sikkerhed og migration. Uden framework-interna, men med konkrete beslutninger, der tæller i hverdagen.

Hvorfor Delphi sidder fast i virksomheder – og hvorfor det ikke nødvendigvis er dårligt

Mange Delphi-applikationer blev opbygget i en tid, hvor desktop-software (VCL, altså den klassiske Windows-grænseflade) var den hurtigste måde at digitalisere processer på. Det gav systemer med høj tæthed af faglogik, tætte database-relationer og mange „små“ særtilfælde, som samlet set bærer driften. Det forklarer langtidsholdbarheden: Forretningslogikken er afprøvet – ikke gennem unit-tests, men gennem mange års produktionsdrift.

Risikoen ligger som regel ikke i Delphi som sprog, men i de tilstødende områder: gamle dataadgange (f.eks. BDE, Borland Database Engine), 32‑bit-afhængigheder, forældet kryptering, uklare grænseflader, manglende observability (Monitoring/Logging), uklare rettighedsmodeller eller manglende opdateringsstrategier. Når disse randområder moderniseres, kan en Delphi-applikation fortsat være en meget pålidelig byggesten i de digitale virksomhedsløsninger.

Typiske udgangssituationer: Sådan ser Delphi Unternehmensanwendungen in der Realität aus

Den, der skal overtage eller stabilisere et Delphi-landskab, støder ofte på hybridformer. Til planlægning og budget er det nyttigt at navngive udgangssituationen klart:

• Monolitisk desktop-klient med direkte databaseadgang (ofte historisk opstået, delvist med „Fat Client“-logik).
• Client-server med services: Windows- und Linux-Services eller Linux-daemon udfører baggrundsopgaver (importer, eksporter, udskriftskørsler, e‑mail, planlægning).
• Hybrid: Desktop forbliver førende, suppleret med en REST-API til portaler eller tredjepartsintegrationer (REST = HTTP-baseret grænseflade, der typisk leverer data som JSON).
• Flere datakilder: SQL Server/PostgreSQL plus „arvegods“ (Firebird, Paradox-filer, DBF, Access).
• Terminalserver/RDS eller Virtual Desktop Infrastruktur (VDI) til central drift, delvist med periferitilkobling (scannere, vægte, etikettetryk).

Hver af disse varianter kan fungere – men moderniseringsfokus er forskellige. En desktop-monolit har ofte først brug for afkobling og tydeligere grænseflader. Et servicelandskab kræver ren driftshåndtering, versionering og overvågning. Og i hybridformer bliver data- og grænsefladestrategien den centrale løftestang.

Modernisering uden Big Bang: Beslutningslogik for IT og beslutningstagere

Den vigtigste beslutning er: Hvad skal stabiliseres på kort sigt, og hvad kan moderniseres trin for trin? Et komplet nybyg har høje risici: parallel fagkonceptudvikling, dobbeltdrift, migrationsvinduer og ofte undervurderede »randfunktioner« (særlige udskrifter, korekturprocesser, nødprocesser). Samtidig må man ikke ignorere reelle blokeringer (fx BDE, ikke patchbare afhængigheder, ikke reviderbar security).

I praksis viser en tredelt køreplan sig effektiv:

• Stabilisere: Build-Prozess, reproducerbare Releases, ren logging, Backup/Restore-Tests, hurtige sikkerhedsforbedringer.
• Afkoble: klare lag (fx Layer-3-Arkitektur: UI, forretningslogik, dataadgang), definere grænseflader, modernisere dataadgang.
• Udvide: REST-APIs, portaler, nye clients, nye databaser, multi-platform, multi-tenant-understøttelse – der hvor det er fagligt og økonomisk hensigtsmæssigt.

Nøglen er, at hvert trin leverer en driftsklar tilstand og ikke kun »forarbejde«. Så bevares proceskapaciteten, og ændringer kan kontrolleres.

Delphi Modernisierung: Wo die größten Risiken wirklich sitzen

Begrebet »modernisering« bruges ofte for generelt. For driften er typisk fem risikozoner afgørende:

1) Dataadgang og driverlandskab (BDE, ODBC, forældede clients)

Den BDE-Ablösung er en klassiker: Så længe Borland Database Engine er i produktionsdrift, opstår konflikter med aktuelle Windows-Versionen, drivere, rettigheder og security-baselines. Derudover bliver driften skrøbelig, fordi komponenter ikke længere vedligeholdes. Her er BDE-Ablösung mit nativer Anbindung ofte det pragmatiske moderniseringstrin: et moderne dataadgangslag i Delphi, som binder forskellige databaser korrekt sammen og håndterer driver-/pooling-emner bedre.

Vigtigt for IT: En BDE-Ablösung er ikke bare »skifte driver«. Typiske efterfølgende opgaver er SQL-dialekt-tilpasninger, transaktionsgrænser (Transaktion = sammenhørende databaseændringer, der enten gennemføres fuldstændigt eller slet ikke), fejlhåndtering, tegnsæt/Unicode og performance-profilering.

2) 32‑Bit-afhængigheder og overgangen til 64‑Bit

Overgangen til 64‑bit fejler sjældent på Delphi selv, men på eksterne komponenter: printerdriver-wrappere, gamle COM/ActiveX-biblioteker, specifikke hardware-SDKs eller forældede database-clients. Til planlægningen er et afhængighedsinventar påkrævet: Hvilke DLLs loaderes? Hvilke komponenter er ikke 64‑bit-kompatible? Findes der erstatninger, eller kan funktionen flyttes til en separat proces (fx som en service)?

En struktureret tilgang er at indføre 64‑bit først dér, hvor det giver driftsmæssige fordele (hukommelsesbehov, store datamængder, moderne platformkrav) – og midlertidigt kapsle 32‑bit for kantfunktioner i stedet for at blokere hele klienten.

3) Unicode-migration og datakonsistens

Unicode betyder: Tekst gemmes ikke længere i lokale kodepages, men i et ensartet tegnsæt (typisk UTF‑16/UTF‑8 afhængig af lag). I gennem årene opbyggede Delphi-applikationer rammer dette gamle datafelter, eksportformater, udskriftsskabeloner og grænseflader. Problemer viser sig ofte først i dagligdagen: specialtegn i navne, internationale adresser, artikeltekster, e-mail-indhold.

For virksomheder er det afgørende at gennemføre en ende-til-ende-kontrol: database-kollation, import/eksport (CSV, XML, JSON), EDI-formater, PDF-generering, SMTP/IMAP, og også visning i UI. En Unicode-migration er mulig, men den kræver tests med reelle data og klare godkendelseskriterier.

4) Schnittstellen und Integrationen (REST, ERP, DMS, Identity)

Mange Delphi-systemer er „øer“, fordi direkte databaseadgang historisk var den hurtigste vej. I dag er der behov for rene integrationer: ERP, DMS, CRM, portaler, maskinforbindelser. Det har vist sig hensigtsmæssigt at udlægge integrationslogikken i REST-Services eller baggrundstjenester. En Delphi REST-API og REST-Server er ikke et mål i sig selv, men en driftskomponent: versionerede endepunkter, klar autentificering, kontrolleret logging og begrænsede dataudleveringer.

Derudover bliver Identity relevant: SAML 2.0 (Single Sign-on mellem virksomhedens identitet og applikation) eller OAuth2/OpenID Connect, afhængig af kontekst. Beslutningen berører ikke kun applikationen, men også drift, auditérbarhed og offboarding-processer.

5) Betrieb: Updates, Monitoring, Recovery

En applikation er i virksomheden kun så god som dens drift. Typiske svagheder: manuelle installationer, manglende rollback-strategi, næsten ingen telemetri, og uklare ansvarsfordelinger ved hændelser. Modernisering betyder her ikke „Cloud“, men: reproducerbare udrulninger, sporbar konfiguration og målbar systemtilstand.

Architektur, die im Alltag hilft: Layer-3, klare Grenzen, weniger Seiteneffekte

Når Delphi-projekter vokser over år, blandes ofte UI-logik med forretningsregler og dataadgang. Det gør ændringer risikable: et nyt felt i dialogen kan pludselig føre til bivirkninger i importer eller rapporter. Layer-3-arkitekturen (præsentation, forretningslogik, dataadgang) er her mindre teori end et praktisk middel til at gøre ændringer kalkulerbare.

Vigtigt er afhængighedsretningen: UI’en må bruge forretningsfunktioner, men forretningslogikken bør ikke vide, hvad knapperne hedder. Dataadgangen leverer objekter/data, men bestemmer ikke faglige regler. Det gør det lettere:

• målrettede tests af forretningsregler, uden at skulle starte UI’en,
• trinvis udskiftning af dataadgang (f.eks. fra BDE til BDE-Ablosung mit nativer Anbindung),
• parallelkørsel af flere brugerflader (desktop plus portal),
• stabilere udgivelser, fordi sideeffekter reduceres.

For beslutningstagere er det et omkostningsargument: Ikke fordi arkitektur „smuk“ er, men fordi den gør vedligeholdelse mere planlægbar.

Modernisering af databaser: FireDAC, PostgreSQL, SQL Server – og hvad det betyder for driften

Beslutninger om databaser er i Delphi-virksomhedsapplikationer ofte historiske. I driften er følgende særligt væsentlige: Backup/Restore, Monitoring, HA/Failover, Security-Patching og rettighedsstyring. Dataadgangen bør matche dette.

FireDAC som standardiseringslag

FireDAC kan fungere som teknisk standardisering, fordi forbindelsesstyring, parameterbinding, transaktioner og valg af driver bliver mere konsistente. Vigtigt for driften: Connection Pooling (genbrug af forbindelser), timeouts, og en klar fejlklassificering (fx „Deadlock“, „Timeout“, „Unique Constraint“).

PostgreSQL i produktion med Delphi: muligheder og faldgruber

PostgreSQL vælges ofte, når åbne standarder, god SQL-funktionalitet og solide driftsmuligheder er vigtige. Typiske punkter i en migration:

• Datatyper: dato/tid, Boolean, UUID, JSONB – brug dem rent i datamodellen i stedet for at gemme alt som tekst.
• Transaktionsisolation: konsistens vs. parallelitet; relevant for bogføringslogik og batchbehandling.
• Indeksstrategi: ydeevne opnås sjældent ved „mere CPU“, men gennem passende indekser og velkonstruerede queries.

For administratorer er det vigtigt, at applikationen ikke kræver „Superuser“-rettigheder, men kører med minimale roller. Det er et centralt punkt i audits og sikkerhedsrevisioner.

Modernisering af SQL Server-tilslutning

I mange miljøer er SQL Server fast etableret. Her handler det mindre om migration og mere om korrekt anvendelse: parameteriserede queries (mod SQL-Injection), fornuftig isolation, anvendelse af Stored Procedures hvor governance kræver det, og en klar adskillelse mellem applikations-login og admin-logins. I praksis er det også værd at kigge på Collations (sortering/tegnsammenligning), da de er relevante ved Unicode-emner og sammenligninger (fx store/små bogstaver).

Eftermonter REST-API: Integrationer muliggøres uden at åbne databasen

Hvis portaler, mobile processer eller tredjepart skal kobles på, er direkte adgang til databasen som regel den dårligste løsning: svær at versionere, risikofyldt for dataintegriteten og stort set ikke auditérbar. En REST-API etablerer et kontrolleret integrationslag. Den definerer, hvilke data i hvilket format og under hvilke regler der er tilgængelige.

For drift og sikkerhed er fire forhold afgørende:

• Autentificering: tokenbaseret, ideelt koblet til centrale identiteter (fx via SAML 2.0/OIDC i et foranliggende gateway, afhængig af arkitektur).
• Autorisation: rettighedstjek på fagobjekter, ikke kun „User darf Endpoint nutzen“.
• Versionering: endpoints eller payload-versioner, så portal og backend kan deployes uafhængigt.
• Rate Limits und Logging: beskyttelse mod misbrug og pålidelig diagnosticering ved fejl.

I mange virksomhedsnetværk kører sådanne services bag en Reverse Proxy (fx nginx). Så skal forwarded-håndteringen være korrekt (ægte Client-IP, HTTPS-detektion, korrekte URL-baser), ellers passer logs, redirects og sikkerhedsregler ikke. Det er ikke en detalje, men relevant for incident-analyse og compliance.

Windows-Service og Linux-Services: korrekt drift af baggrundsprocesser

Delphi bruges i virksomheder ikke kun til desktop-klienter, men også til tjenester: dataimporter, scheduler, mailafsendelse, PDF-generering, grænseflade-workere. Til drift er det væsentligt, at en service ikke bare „kører et eller andet“, men kan startes, stoppes og overvåges kontrolleret.

Tjekliste for serviceegnede Delphi-komponenter

• Ekstern konfiguration: ingen „faste“ stier/hosts i binærfilen; konfiguration som fil/miljøvariabler, med klart dokumenteret opsætning.
• Graceful Shutdown: afslut igangværende job pænt eller afbryd dem ordentligt, så der ikke opstår halvfærdige dataregistre.
• Idempotens: gentagen udførelse af et job må ikke skabe dobbelte posteringer (idempotens = samme kald, samme resultat).
• Logging med korrelation: pr. opgave/transaktion en ID, så logs kan sammenføjes på tværs af komponenter.
• Overvågning: health-endpoints eller mindst verificerbare metrikker (f.eks. „sidste kørsel“, „fejlfrekvens“, „kø“).

Ved Linux-services (f.eks. som daemon under systemd) kommer paketering, rettighedskoncept og filsystem-layout til. Afgørende er, at service-identiteten tildeles mindst mulige rettigheder, og at secrets (adgangskoder, Tokens) ikke ligger i klartekst i deployment. Afhængig af miljø kan et Secret-Store eller mindst en sikret konfigurationssti være nødvendig.

Sikkerhed og compliance: Hvad der typisk skal følges op på for Delphi-applikationer

Mange eksisterende applikationer er funktionelt korrekte, men security blev „den gang“ vurderet anderledes. I dag er kravene tydeligere: patchbarhed, sporbarhed, kryptering, adgangskontrol. Typiske foranstaltninger med høj nytte/risiko-effekt:

• Transportkryptering: TLS for services og API-kommunikation; ingen ukrypterede HTTP-forbindelser i det interne net af vane.
• Håndtering af adgangskoder og secrets: ingen adgangskoder i INI-filer uden beskyttelse; hvis muligt central identity og token-håndtering.
• Audit-logging: hvem udførte hvilken kritisk handling (stamdata, godkendelser, eksporter), med tidsstempel og identitet.
• Rettighedskoncept: modeller roller og rettigheder fagligt; adskil admin-funktioner; gennemgå multitenancy/mandantadskillelse.
• Kryptografi pragmatisk korrekt: ingen hjemmelavede procedurer; brug etablerede metoder som AES (symmetrisk) og aktuelle hashes, plus integritetsbeskyttelse.

Vigtigt: Security er ikke kun kode. Det berører også drift (adgangsrettigheder på servere, opbevaring af logs, kryptering af backups) og processer (incident response, regelmæssige opdateringer, udfasning af komponenter).

Planlæg migration: Fra det „opvoksede system“ til en roadmap-egnet platform

Hvis en Delphi-applikation skal føres strategisk videre, behøver den en roadmap, der forbinder tekniske og organisatoriske aspekter. En praksisnær tilgang starter med transparens:

1) Teknisk kortlægning, der dækker drift og risiko

• Komponentliste (Delphi-versioner, tredjepartsbiblioteker, drivere, services, installer)
• Databaser og dataflow (import/eksport, batch-jobs, rapportering)
• Grænseflader (fil, TCP/IP, REST, SOAP, e-mail, ERP/DMS/CRM)
• Udrulnings- og opdateringsproces (manuel, scripts, central distribution)
• Fejlprofil (hyppige fejl, ydeevne-flaskehalse, gendannelsestider)

2) Definér målbildet, men overbelast det ikke

Et målbild er nyttigt, når det gør beslutninger lettere. Det bør beskrive, hvordan fremtidige releases tilbliver, hvordan grænseflader skal se ud, hvordan dataadgang standardiseres, og hvordan driften overvåges. Det behøver ikke betyde „alt nyt“. Ofte er et målbild med tre til fem føringslinjer tilstrækkeligt: f.eks. FireDAC som standard, REST til integrationer, services med monitoring, tilslutning til identity, klare lagdelinger.

3) Implementering i afgrænsede pakker

Moderniseringspakker bør være fagligt og teknisk afgrænsede: „BDE fjernes og dataadgang standardiseres“, „REST-API til portal-use-cases“, „64‑bit-klient plus kompatibilitetskapsel“, „styrke service-driften“. Hver pakke kræver acceptkriterier: målelig stabilitet, defineret ydeevne, dokumenterede driftsprocesser.

C# und Delphi zusammenbringen: Wenn Portale und Services neben dem Desktop entstehen

I mange virksomheder er Delphi fast forankret i kernesystemet, mens portaler eller nye integrationsservices i højere grad opstår i C#/.NET. Det er ikke et modsætningsforhold, så længe arkitekturen skiller klart: Delphi kan fortsætte med at drive det procesnære desktop-system stabilt, mens C# Portale eller C# Services dækker moderne web-krav. Det væsentlige er et fælles sprog mellem systemerne: klare datakontrakter, konsistente identiteter, sporbare grænsefladeversioner og ensartet monitoring på tværs af systemgrænser.

For IT-ledelsen er det ofte den økonomisk mest fornuftige vej: Den eksisterende værdiskabelse forbliver tilgængelig, mens nye kanaler etableres uden komplet migration.

Hvad I bør forberede internt: Dokumentation, driftshåndbog, vidensoverførsel

Delphi-systemer bæres ofte af få personer. Det er en risiko, som kan reduceres med overskuelig indsats. Især effektive er:

• Driftshåndbog: tjenester, porte, konfiguration, Cron/Scheduler, typiske fejl, gendannelsesprocedurer.
• Release-noter: hvad ændrer sig, hvilke DB-migrationer køres, hvordan er rollback mulig?
• Grænsefladekatalog: endpoints/formater, filudveksling, kontaktpersoner, versioner.
• Oversigt over datamodellen: centrale tabeller/entiteter, nøgler, multi-tenant-logik, arkivering.

Det er ikke bureaukrati, men fundamentet for planlagt drift, hurtigere incident-håndtering og mindre afhængighed af enkelte medarbejdere.

Konklusion: Delphi-virksomhedsapplikationer er ikke problemet – manglende moderniseringsveje er det

Delphi-virksomhedsapplikationer kan i årevis være en pålidelig, økonomisk kerne for procesnære softwareløsninger. Det kritiske punkt er sjældent sproget, men summen af aldrende drivere, uklare grænseflader, manglende hardening af drift og forsømte sikkerhedsmekanismer. Den, der planlægger stabilisering, afkobling og udvidelse som en kontrolleret roadmap, undgår den risikable Big Bang – og opnår alligevel REST-integrationer, 64‑bit-kompatibilitet, rene dataadgange og en drift, der matcher nutidige krav.

Hvis I vil teknisk placere jeres Delphi-landskab og opstille en robust moderniseringsvej for dataadgang, grænseflader og drift, kontakt os:

Drøft projekt eller moderniseringsprojekt med Net-Base.