Question 1

Hvornår er Delphi-modernisering at foretrække frem for komplet nyudvikling?

Accepted Answer

Når faglogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte økonomisk mere fordelagtig end en nyopstart, der medfører tab af funktionalitet og høj implementeringsrisiko.

Question 2

Kan den samme domænelogik køre for Windows, macOS og Linux?

Accepted Answer

Ja. Især i Delphi-projekter planlægger vi fælles forretningslogik og adskiller brugergrænseflade, services og dataadgang, så flere platforme kan forsynes ensartet og stabilt.

Question 3

Bygger Net-Base også REST-servere og baggrundstjenester?

Accepted Answer

Ja. Windows- og Linux-services, REST-APIs, integrationslag og deployment er for os en del af arkitekturen og eftermonteres ikke.

Question 4

Hvordan starter et typisk projekt?

Accepted Answer

Som regel med en struktureret kortlægning: mål, eksisterende systemer, database, platforme, grænseflader og driftsrisici. Deraf opstår et realistisk skræddersybart udgangspunkt.

Question 5

Overtager I også eksisterende Delphi-systemer?

Accepted Answer

Ja. Vi træder regelmæssigt ind i eksisterende Delphi-applikationer, analyserer kodebasen, dataadgang, arkitektur og særtilfælde og videreudvikler dem kontrolleret.

Question 6

Kan REST-servere, portaler og desktop-klienter opstå som en del af et projekt?

Accepted Answer

Ja. Især i virksomhedsapplikationer planlægger vi disse byggeblokke bevidst samlet, så den samme forretningslogik ikke splittes ud over flere specialløsninger.

Question 7

Er en BDE-afløsning også mulig uden komplet udskiftning?

Accepted Answer

I mange tilfælde, ja. Vi udskiller dataadgang, SQL og deployment trinvis fra den eksisterende legacy-struktur og opbygger en native, vedligeholdbar integration.

Question 8

Understøtter I også drift og videreudvikling?

Accepted Answer

Ja. Release-processer, hosting, fejlanalyse, databasevedligeholdelse og senere udvidelser er en del af vores arbejdsområde.

Question 9

Hvornår er Delphi hensigtsmæssigt i forhold til en komplet ny platform?

Accepted Answer

Når opbygget faglogik, højtydende desktop-processer og multiplatformmål skal videreføres økonomisk, i stedet for at erstatte substansen letfærdigt.

Question 10

Hvornår anvender De derudover C#?

Accepted Answer

Især til portaler, Web-Backends, REST-Services, integrationer og serviceorienterede arkitekturdele, der kan integreres godt med eksisterende desktop-systemer.

Question 11

Hvor vigtigt er Layer-3 i praksis?

Accepted Answer

Først den klare adskillelse af UI, forretningslogik og dataadgang gør modernisering, tests, services og fremtidige platformskift håndterbare.

Question 12

Medtænker I nye platforme som Windows 11 ARM64 tidligt?

Accepted Answer

Ja. Ny målhardware og implementeringsstier valideres tidligt, så de ikke senere udvikler sig til omkostningstunge specialprojekter.

Question 13

Arbejder I primært med enkeltstående engangsværktøjer eller med systemer med længere levetid?

Accepted Answer

Vægten ligger på systemer med drift, ansvar og løbende videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.

Question 14

Kan eksisterende produkter eller interne systemer moderniseres parallelt?

Accepted Answer

Ja. Især for systemer, der er vokset over længere tid, planlægger vi ofte en trinvis videreudvikling, så drift og modernisering er forenelige.

Question 15

Er hosting og teknisk drift en del af jeres arbejde?

Accepted Answer

Ja. Release, hosting, overvågning og driftsansvar indgår i vores projektplanlægning, så den færdige løsning ikke kun udvikles, men også kan drives driftssikkert.

Question 16

Er individuel virksomhedssoftware kun relevant for meget store virksomheder?

Accepted Answer

Nej. Det er altid lønsomt, når standardsoftware kun kan afbilde processer via omveje, mediebrud eller dyre særregler, og den reelle værdi ligger i ren faglogik.

Question 17

Hvorfor lægger I så stor vægt på Layer-3 i virksomhedsapplikationer?

Accepted Answer

Fordi først adskillelsen af UI, forretningslogik og dataadgang sikrer, at rapportering, nye klienter, tjenester og fremtidige udvidelser forbliver økonomisk kontrollerbare.

Question 18

Kan I også integrere jer i eksisterende, over tid opbyggede processer?

Accepted Answer

Ja. Netop dér bliver vores arbejde stærkt, fordi vi først gør fagprocesser, eksisterende data og gammel logik læsbare og derudfra udvikler en robust målarkitektur.

Question 19

Kan der med Delphi ud over Windows også medtænkes macOS, Linux, iOS og Android?

Accepted Answer

Ja. Afhængigt af projektmålet planlægger vi desktopmål, mobile brugerflader og servernære komponenter ud fra en fælles faglig linje, i stedet for at bygge hver platform fagligt forfra.

Question 20

Hvordan undgår I, at multiplatformprojekter fagligt løber fra hinanden?

Accepted Answer

Gennem en fælles kode- og arkitekturstrategi: forretningsregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst indkapsles.

Question 21

Er mobile udvidelsesfaser også mulige senere?

Accepted Answer

Ja. Hvis arkitektur, services og grænseflader er korrekt forberedt, kan iOS- eller Android-mål integreres senere langt mere kontrolleret.

Question 22

Udvikler I både REST-servere og Windows- og Linux-services?

Accepted Answer

Ja. Baggrundstjenester, API'er, importer, eksporter, portaler og teknisk driftslogik hører til vores tilbagevendende opgaveprofiler.

Question 23

Hvornår har en virksomhedsapplikation desuden brug for en portal?

Accepted Answer

Når kunder, partnere eller interne roller skal have kontrolleret adgang til de samme processer, uden at faglige regler duplikeres i separate grænseflader.

Question 24

Hvordan sikrer man, at rettigheder, logning og processer forbliver konsistente mellem klient og server?

Accepted Answer

Ved ikke at gemme fagregler i enkelte endepunkter eller UI'er, men ved at skabe et klart fagligt centrum, som Client, Portal og Service kan bruge i fællesskab.

Question 25

Kan eksisterende grænseflader og datastrømme moderniseres uden et Big Bang?

Accepted Answer

Ja. I mange projekter omarrangerer vi mappings, database­stier, jobs og integrationer trinvis, så de reelle processer kan fortsætte med at køre.

Question 26

Påtager I jer også integrationer til finansbogføring og tredjepartssystemer?

Accepted Answer

Ja. Især Fibu, APIs, CRM, lager, licenslogik eller branchespecifikke tredjepartssystemer skal være omhyggeligt dokumenterede, monitorerbare og fagligt kontrollerbart tilsluttede.

Question 27

Tænker I platformmål som Windows 11 ARM64 med i sådanne integrationsprojekter fra starten?

Accepted Answer

Ja. Nye målplatforme, native afhængigheder og fremtidige deploymentsveje hører tidligt hjemme i samme planlægning som grænseflader og dataflowlogik.

Question 28

Hvorfor satser I stadig bevidst på Delphi?

Accepted Answer

Fordi Delphi i mange virksomhedsapplikationer tilbyder en stærk kombination af veletableret forretningslogik, højtydende desktopprocesser, tæt databaseintegration og kontrollerbar videreudvikling.

Question 29

Er Delphi kun relevant for modernisering af eksisterende systemer?

Accepted Answer

Nej. Delphi er også relevant for nye virksomhedsapplikationer, når produktive desktopprocesser, rapporter, lokal integration og en fælles faglig base for flere platforme er vigtige.

Question 30

Hvor ligger grænserne for Delphi?

Accepted Answer

Især der, hvor et projekt primært er portal-, service- eller cloudcentreret. Så kombinerer vi Delphi bevidst med C#, REST-servere eller webkomponenter i stedet for at tvinge alt ind i et værktøj.

Question 31

Hvornår er C# at foretrække frem for Delphi?

Accepted Answer

Især når et projekt primært består af REST-API'er, portaler, backend-tjenester, integrationer eller cloudnære driftsmodeller.

Question 32

Bruger I C# også sammen med eksisterende Delphi-systemer?

Accepted Answer

Ja. Netop denne kombination er ofte fornuftig: Delphi bærer produktiv forretningslogik i klienten, mens C# services, portaler og API-lag supplerer den på en ryddelig måde.

Question 33

Hvad er typiske risici ved C#-projekter?

Accepted Answer

Ofte bygges der teknisk moderne for hurtigt uden at adskille roller, forretningslogik, logging, deployment og reelle driftsmæssige spørgsmål tidligt og ordentligt. Netop dér griber vi ind.

Question 34

Hvorfor er Layer-3 så vigtigt i virksomhedsapplikationer?

Accepted Answer

Fordi kun den klare adskillelse af UI, forretningslogik og dataadgang sikrer, at udvidelser, tests, services og nye platforme ikke direkte fejler på monolitten.

Question 35

Er Layer-3 kun relevant for store projekter?

Accepted Answer

Nej. Især mellemstore systemer drager stor fordel af det, fordi senere krav kan integreres langt mere kontrolleret.

Question 36

Hvad er den hyppigste fejl ved Layer-3?

Accepted Answer

At lagene kun tegnes formelt, mens de egentlige regler fortsat er gemt i UI-koden eller direkte i særlige SQL-stier. Så findes opbygningen kun på slides, ikke i systemet.

Question 37

Hvornår er det hensigtsmæssigt med en ekstern Delphi-udvikler?

Accepted Answer

Især når viden om det eksisterende mangler, moderniseringen er gået i stå, eller en applikation skal funktionelt videreudvikles uden at miste sin substans.

Question 38

Kan De også arbejde med eksisterende Delphi-applikationer?

Accepted Answer

Ja. Netop det er et fokusområde: Vi analyserer legacykode, database, deployment, særlige tilfælde og faglige arbejdsgange og bygger derpå kontrolleret videre.

Question 39

Handler det kun om programmering, eller også om teknisk retning?

Accepted Answer

Det handler udtrykkeligt også om retning. God Delphi-udvikling omfatter for os arkitektur, dataadgang, integrationer, REST-services og den reelle drift.

Question 40

Hvad indgår i en god Delphi-vedligeholdelse?

Accepted Answer

Fejlanalyse, videreudvikling, databasevedligeholdelse, udrulningsstøtte, teknisk dokumentation og en arkitektur, der ikke altid gør nye krav dyrere.

Question 41

Kan support også starte uden en komplet ombygning?

Accepted Answer

Ja. Ofte begynder den med stabilisering, synliggørelse af risici og en prioriteret liste over tekniske og faglige forbedringer.

Question 42

Hvordan reducerer I afhængigheden af enkeltpersoners viden?

Accepted Answer

Ved at dokumentere dataveje, komponenter, build-trin og kritisk forretningslogik på en struktureret måde og omdanne implicit viden til efterprøvbar systemlogik.

Question 43

Skal en gammel Delphi-applikation fuldstændigt erstattes?

Accepted Answer

Nej. Ofte er en kontrolleret omstrukturering mere hensigtsmæssig: forny dataadgangen, afkoble logikken, udvide services og målrettet modernisere brugergrænseflader.

Question 44

Hvordan undgår man driftsafbrydelse ved modernisering?

Accepted Answer

Gennem klare mellemtrin, rene grænseflader og en migreringsvej, hvor gamle og nye komponenter kan eksistere kontrolleret side om side.

Question 45

Kan eksisterende forretningslogik senere også overføres til services eller portaler?

Accepted Answer

Ja. Netop derfor ekstraherer vi forretningslogikken fra UI-nær legacy-kode og organiserer den i en struktur, som Clients, Services og API'er kan anvende på tværs.

Question 46

Er det muligt at skifte til FireDAC eller native drivere uden en komplet ombygning?

Accepted Answer

Ja, ofte i faser. Det er vigtigt at gennemgå SQL, datatyper, transaktioner og specialtilfælde grundigt i stedet for blot at erstatte komponenter 1:1.

Question 47

Hvorfor berører udskiftningen af BDE næsten altid også databasestrukturen?

Accepted Answer

Fordi der derved ofte bliver synlige gamle tabeller, indekser, tegnsæt og historisk opståede SQL-stier, som også bør medtages i oprydningen for at sikre stabilitet og ydeevne.

Question 48

Hvad opnår man konkret med native databaseforbindelse?

Accepted Answer

Enklere udrulning, bedre vedligeholdelse, kontrollerbare forbindelser og et væsentligt bedre grundlag for services, API'er og fremtidige udvidelser.

Question 49

Hvornår er PostgreSQL et godt valg for Delphi?

Accepted Answer

Når stabilitet, drift med flere samtidige brugere, klare SQL-stier, åben infrastruktur og ren udvidbarhed for Desktop, Services eller Portale er vigtige.

Question 50

Er FireDAC altid den rigtige vej?

Accepted Answer

FireDAC er ofte en meget god tilgang, men ikke som en blind udskiftning. Afgørende er SQL-adfærd, datatyper, transaktioner, fejlforløb og det konkrete datasæt.

Question 51

Kan BDE-, Paradox- eller ældre SQL-systemer migreres trinvist til PostgreSQL?

Accepted Answer

Ja. I mange tilfælde er en kontrolleret trinvis tilgang mere omkostningseffektiv end et abrupt brud, så længe datamodellen og forretningslogikken er konsekvent indtænkt.

Question 52

Kan man med Delphi udvikle produktionsklare REST-API'er?

Accepted Answer

Ja. Især når den samme forretningslogik allerede findes i Delphi-bestand, er en velafgrænset REST-server ofte mere økonomisk end en fuldstændig ny parallelverden.

Question 53

Hvornår er en REST-server at foretrække frem for direkte adgang til databasen?

Accepted Answer

Når flere klienter, portaler, tjenester eller integrationer kontrolleret skal anvende de samme regler, og direkte SQL-adgang fagligt bliver for risikabelt.

Question 54

Hvordan sikrer I konsistens mellem Delphi-klienten og REST?

Accepted Answer

Gennem en arkitektur, hvor forretningsregler ikke forbliver skjult i formularer, men stilles til rådighed for klient, API og baggrundsprocesser.

Question 55

Hvornår har en virksomhedsapplikation brug for yderligere Windows- eller Linux-services?

Accepted Answer

Når importer, eksporter, tidsstyring, synkronisering, licenslogik eller integrationer ikke skal være bundet til en aktiv brugersession på skrivebordet.

Question 56

Kan Services og REST stamme fra den samme arkitektur?

Accepted Answer

Ja. Netop — det er ofte fornuftigt, fordi forretningslogik, datamodel og logging dermed ikke fordeles på flere tekniske øer.

Question 57

Hvad er særligt vigtigt for tjenester i produktion?

Accepted Answer

Klar fejlhåndtering, observerbare tilstande, genstartssikkerhed, logging, deployment og en fagligt konsistent behandling i stedet for stiltiende baggrundsmagi.

Question 58

Kan den samme applikation virkelig køre på Windows, macOS og Linux?

Accepted Answer

Ja, hvis brugergrænseflade, domænelogik, platformsspecifikke forhold og release-processer ikke blandes, men derimod klart struktureres.

Question 59

Hvad er den hyppigste fejl i multiplatformprojekter?

Accepted Answer

Det er for sent at tage højde for filsystem, udskrivning, signering, målplatforme, pakning og UI-forskelle. Så bliver multiplatform hurtigt dyrt og inkonsistent.

Question 60

Kan Services og API'er bruge den samme domænelogik?

Accepted Answer

Ja. En god arkitektur sikrer, at ikke hver platform udvikler sin egen faglige særvej.

Question 61

Hvornår har en virksomhedsapplikation brug for en yderligere REST-server?

Accepted Answer

Så snart flere klienter, portaler, mobile adgangsformer, eksterne integrationer eller løst koblede processer skal kontrolleret bruge den samme forretningslogik.

Question 62

Understøtter I også Windows- og Linux-tjenester?

Accepted Answer

Ja. Baggrundsprocesser, tidsplanlægning, synkronisering, eksporter, licenstjenester og tekniske støtteprocesser hører til vores typiske opgaver.

Question 63

Hvordan opretholdes faglig konsistens mellem Client, REST og Service?

Accepted Answer

Gennem en arkitektur, hvor forretningsregler ikke er skjult i enkeltstående brugerflader, men forbliver fælles anvendelige og efterprøvelige.

Question 64

Hvorfor bør Windows 11 ARM64 allerede tages i betragtning i dag?

Accepted Answer

Fordi nye hardwareklasser og mobile arbejdspladser i stigende grad bygger på det, og teknisk efterarbejde senere bliver betydeligt dyrere end en tidlig arkitekturbeslutning.

FAQ Virksomhedssoftware

FAQ Virksomhedssoftware – Overblik

Vigtige fordybninger i dette emne

Projektstart, arkitektur & samarbejde

Ydelser i overblik

Teknologi og arkitektur i overblik

Projektbilleder og referencemønstre

Skræddersyet virksomhedssoftware & Layer-3

Multiplatform med Delphi

Services, REST-servere & portaler

Grænseflader, dataflows & platformsmål

Delphi til virksomhedsapplikationer

C# til services & portaler

Layer-3-arkitektur

Delphi-udviklere fra Freiburg

Delphi-Vedligeholdelse & Support

Delphi-Modernisering

BDE-Afløsning

Delphi, PostgreSQL & FireDAC

Delphi REST-API & REST-Server

Windows- & Linux-tjenester

Delphi tværplatform

REST-Server & tjenester

Windows 11 ARM64

Hvis I har et konkret moderniserings-, API- eller platformsspørgsmål, bør vi tidligt afklare den tekniske afgrænsning.