FAQ-landingside
Centrale spørgsmål og svar om projektstart, ydelser, virksomhedssoftware, Delphi, arkitektur, portaler, tjenester og modernisering.
Denne side samler de mest almindelige spørgsmål fra vores startside, oversigtssider og faglige undersider ét sted. De kompakte FAQ forbliver bevidst på de respektive detaljesider. Her organiserer vi dem yderligere som landingside, så interessenter hurtigt kan se, hvilke emner vi virkelig mestrer inden for projektstart, ydelser, Delphi, C#, Layer-3, portaler, modernisering, dataadgang og platformstrategi.
Du kan enten springe direkte til en temablok eller fra neden skifte til den dybdegående underside. Dermed fungerer siden både som et hurtigt indgangspunkt og som et struktureret FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbejde
Spørgsmål om en fornuftig start, kortlægning af eksisterende systemer og tidlige arkitekturvalg.
Direkte til svarene
Ydelser
Oversigt over ydelser
Spørgsmål om overtagelse af eksisterende løsninger, modernisering, services, dataadgang og langsigtet support.
Direkte til svarene
Teknologier
Teknologi og arkitektur i overblik
Spørgsmål om Delphi, C#, Layer-3, valg af platform og den tekniske retning på tværs af flere udvidelsesfaser.
Direkte til svarene
Projekter
Projektbilleder og referencemønstre
Spørgsmål om projektstørrelse, driftsansvar, hosting, produktlogik og langtidsholdbare systemer.
Direkte til svarene
Virksomhedssoftware
Skræddersyet virksomhedssoftware & Layer-3
Spørgsmål om rentabilitet, proceslogik, roller, data og langsigtet udvidelsesmulighed.
Direkte til svarene
Ydeevne
Multiplatform med Delphi
Spørgsmål om Windows, macOS, Linux samt senere iOS- og Android-spor baseret på delt faglogik.
Direkte til svarene
Ydeevne
Services, REST-servere & portaler
Spørgsmål om portaler, API’er, Windows- og Linux-services som del af samme fagarkitektur.
Direkte til svarene
Integration
Grænseflader, dataflows & platformsmål
Spørgsmål om Fibu, API’er, databaseombygning, mapping, overvågning og nye målplatforme.
Direkte til svarene
Delphi
Delphi for virksomhedsapplikationer
Hvorfor Delphi kan forblive stærk ved etableret forretningslogik, rapporter og produktive desktopprocesser.
Direkte til svarene
C#
C# til services & portaler
Spørgsmål om REST, integrationer, portaler, backend-tjenester og stabil drift.
Direkte til svarene
Arkitektur
Layer-3-arkitektur
Spørgsmål om adskillelse af UI, forretningslogik og dataadgang, og hvorfor det er økonomisk direkte relevant.
Direkte til svarene
Delphi-Team
Delphi-udviklere fra Freiburg
Spørgsmål om ekstern støtte, overtagelse af eksisterende systemer og teknisk ansvar i etablerede Delphi-systemer.
Direkte til svarene
Support
Delphi-Vedligeholdelse & support
Spørgsmål om stabilisering, videreudvikling, release-sikkerhed og reduktion af enkeltpersonsviden.
Direkte til svarene
Modernisering
Delphi-Modernisering
Spørgsmål om ombygningsvej, risiko, bevarelse af domænelogik og trinvise fornyelser i løbende drift.
Direkte til svarene
Dataadgang
BDE-Ablösung
Spørgsmål om FireDAC, native drivere, SQL-særheder, Deployment og omstrukturering af databasen.
Direkte til svarene
PostgreSQL
Delphi, PostgreSQL & FireDAC
Spørgsmål om PostgreSQL-migrering, native drivere, SQL-adfærd og en rolig ombygning af dataadgangen.
Direkte til svarene
Delphi REST
Delphi REST-API & REST-Server
Spørgsmål om REST med Delphi, API-afgrænsning, fælles domænelogik og ren serverarkitektur.
Direkte til svarene
Tjenester
Windows- & Linux-tjenester
Spørgsmål om baggrundstjenester, tidsplanlægning, overvågning, genstartsadfærd og klar driftsafgrænsning.
Direkte til svarene
Teknologi
Delphi Multiplatform
Spørgsmål om fælles kodebase for Windows, macOS og Linux med kontrollerede platformgrænser.
Direkte til svarene
Serverarkitektur
REST-Server & tjenester
Spørgsmål om API’er, Windows- og Linux-tjenester, serverlogik, overvågning og driftsansvar.
Direkte til svarene
Platform
Windows 11 ARM64
Spørgsmål om ny hardware, native afhængigheder, drivere, builds og rollout-stier.
Direkte til svarene
Projektstart
Projektstart, arkitektur & samarbejde
Mange første spørgsmål handler ikke om en enkelt teknologi, men om det rigtige udgangspunkt: Hvad bør afklares først, hvordan opstår teknisk orientering, og hvordan bliver en idé til en holdbar indgang til et reelt projekt?
På startsiden dukker typisk de første orienteringsspørgsmål op: Hvordan starter et projekt fornuftigt, hvilke arkitekturspørgsmål bør afklares tidligt, og hvornår er modernisering mere hensigtsmæssig end en hektisk nyudvikling?
Hvornår er Delphi-modernisering mere fordelagtig end en komplet nyudvikling?
Hvis forretningslogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte mere økonomisk end en genstart med tab af funktionalitet og høj implementeringsrisiko.
Kan den samme forretningslogik køre for Windows, macOS og Linux?
Ja. Især i Delphi-projekter planlægger vi fælles forretningslogik og adskiller præsentation, services og dataadgang, så flere platforme kan forsynes konsekvent.
Bygger Net-Base også REST-servere og baggrundstjenester?
Ja. Windows- og Linux-services, REST-APIs, integrationslag og deployment hører for os til arkitekturen og tilføjes ikke først efterfølgende.
Hvordan starter et typisk projekt?
Som regel med en struktureret kortlægning: mål, eksisterende systemer, database, platforme, grænseflader og driftsrisici. Deraf opstår et realistisk tilpasset startpunkt.
Læs emnet detaljeret
Hvis du vil gå fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og relaterede emner.
Ydelser
Overblik over ydelser
På ydelser-siden opstår ofte de mest omfattende opfølgningsspørgsmål: Hvad overtager vi konkret, hvor langt rækker vores tekniske ansvar, og hvordan spiller modernisering, integrationer, drift og videreudvikling sammen?
Især ved voksede applikationer opstår ofte de samme faglige og tekniske spørgsmål. Disse punkter afklarer vi tidligt, før et projekt udvikler sig til et diffust storprojekt.
Overtager I også eksisterende Delphi-systemer?
Ja. Vi træder regelmæssigt ind i voksede Delphi-applikationer, analyserer eksisterende systemer, dataadgang, arkitektur og specialtilfælde og videreudvikler dem kontrolleret.
Kan REST-servere, portaler og desktop-klienter opstå i ét projekt?
Ja. Især for virksomhedsapplikationer planlægger vi disse byggelementer bevidst sammen, så den samme forretningslogik ikke splittes op i flere specialløsninger.
Er en BDE-udskiftning også mulig uden komplet udskiftning?
I mange tilfælde ja. Vi løsriver dataadgang, SQL og deployment trinvis fra den gamle struktur og etablerer en native, vedligeholdelsesvenlig tilslutning.
Understøtter I også drift og videreudvikling?
Ja. Release-processer, hosting, fejlanalyse, databasevedligehold og senere udvidelser er en del af vores arbejdsområde.
Læs emnet detaljeret
Hvis I fra denne FAQ vil skifte til den mere dybdegående faglige side, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Teknologier
Teknologi og arkitektur i oversigt
Denne FAQ samler de typiske orienteringsspørgsmål ved teknologivalg: Hvornår er Delphi stærk, hvornår er C# den bedre byggesten, og hvordan fører en ren arkitektur flere platforme, services og klienter sammen på kontrolleret vis?
Teknologiske beslutninger skal passe til teamet, fagdomænet og driften. Netop derfor afklarer vi disse spørgsmål ikke abstrakt, men altid ud fra det konkrete system.
Hvornår er Delphi fornuftigt i stedet for en komplet ny platform?
Når eksisterende faglogik, performante desktop-processer og multiplatformsmål økonomisk skal videreføres fremfor at erstatte substans uden overvejelse.
Hvornår anvender I supplerende C#?
Frem for alt til portaler, web-backends, REST-services, integrationer og serviceorienterede dele af arkitekturen, som kan integreres hensigtsmæssigt med eksisterende desktop-systemer.
Hvor vigtig er Layer-3 i praksis?
Meget. Først den klare adskillelse mellem UI, forretningslogik og dataadgang gør modernisering, tests, services og kommende platformskift håndterbare.
Tænker I nye platforme som Windows 11 ARM64 ind tidligt?
Ja. Ny målhardware og deploymentsveje vurderes tidligt, så de senere ikke bliver til omkostningstunge særprojekter.
Læs emnet i detaljer
Hvis I fra denne FAQ vil skifte til den mere dybdegående faglige side, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Projekter
Projektbilleder og referencemønstre
Den, der ser på projektsiden, vil som regel forstå, hvilken type projekter vi reelt håndterer: enkeltstående værktøjer eller længerevarende systemer med drift, rettighedskoncept, versioner, integrationer og reel videreudvikling.
Mange projekter fremstår indledningsvis forskellige, men deler fælles mønstre: opvokset faglogik, integrationer, rettigheder, versionering, driftsmæssige spørgsmål og langtidsholdbar udbygning.
Arbejder I primært med enkeltstående værktøjer eller med længerevarende systemer?
Fokus ligger på systemer med levetid, ansvar og videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Særligt for længere opvoksede systemer planlægger vi ofte en trinvist gennemført modernisering, så drift og modernisering harmonerer.
Er hosting og teknisk drift en del af jeres leverance?
Ja. Release, hosting, overvågning og driftsansvar indgår i vores projektplanlægning, så den færdige løsning ikke blot udvikles, men også kan drives holdbart.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, begrundelser for beslutninger og tilstødende emner.
Virksomhedssoftware
Individuel virksomhedssoftware & Layer-3
Disse spørgsmål opstår typisk, når standardsoftware fagligt ikke længere slår til, og virksomheden vil vide, om et individuelt system kan opbygges økonomisk forsvarligt, vedligeholdelsesvenligt og med mulighed for udbygning.
Især ved individuel virksomhedssoftware handler det ikke kun om enkelte skærmbilleder, men om roller, data, revisionsspor og en arkitektur, som forbliver fleksibel på længere sigt.
Er individuel virksomhedssoftware kun relevant for meget store virksomheder?
Nej. Den lønner sig altid, når standardsoftware kun kan afbilde processer via omveje, mediebrud eller dyre særregler, og den egentlige værdi ligger i ren faglogik.
Hvorfor fremhæver I Layer-3 så kraftigt i virksomhedsapplikationer?
Fordi først adskillelsen af UI, forretningslogik og dataadgang sikrer, at rapportering, nye klienter, services og kommende udvidelser forbliver økonomisk kontrollerbare.
Kan I også tage fat i eksisterende, tilvoksede processer?
Ja. Netop dér bliver vores arbejde stærkt, fordi vi gør fagprocesser, eksisterende data og gammel forretningslogik læsbare og udvikler derudfra en robust målarkitektur.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, begrundelser for beslutninger og tilstødende emner.
Se individuel virksomhedssoftware & Layer-3-applikationer i detaljer
Ydelse
Multiplatform med Delphi
Virksomheder spørger her som regel ikke kun efter en teknisk mulighed, men efter en holdbar strategi: Hvilke dele forbliver fælles, hvad må håndteres platformspecifikt, og hvordan undgår man en dyr parallelopbygning?
Multiplatform bliver først værdifuld, når den samme faglogik forbliver samlet og kontrolleret på tværs af flere målsystemer, og platformspecifikke forskelle synliggøres tidligt.
Kan der med Delphi ud over Windows også macOS, Linux, iOS og Android medtænkes?
Ja. Afhængigt af projektets mål planlægger vi desktop-mål, mobile brugerflader og servernære komponenter ud fra en fælles faglig linje i stedet for at bygge hver platform fagligt forfra.
Hvordan undgår I, at multiplatform-projekter fagligt glider fra hinanden?
Gennem en fælles kode- og arkitekturstrategi: fagregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst kapsles.
Er mobile udvidelser også mulige senere?
Ja. Hvis arkitektur, services og grænseflader er ordentligt forberedt, kan iOS- eller Android-mål senere tilsluttes betydeligt mere kontrolleret.
Læs mere om emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående faglige side, finder du der den større sammenhæng mellem arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Ydelser
Services, REST-server & portaler
Især her må rettigheder, dataflows, logning og faglige regler forblive samlet. Derfor behandler vi emnet ikke som en web-tilføjelse, men som en ordnet udbygning af samme applikationslinje.
Portaler, REST-APIs og tjenester fungerer kun godt, hvis de fagligt ikke står ved siden af kernesystemet, men viderefører den samme data- og rollelogik konsekvent.
Udvikler I både REST-servere samt Windows- og Linux-services?
Ja. Baggrundstjenester, APIs, importer, eksporter, portaler og teknisk driftslogik hører til vores tilbagevendende opgaveområder.
Hvornår har en virksomhedsapplikation yderligere brug for en portal?
Altid når kunder, partnere eller interne roller skal kontrolleret have adgang til de samme processer, uden at man duplikerer faglige regler i separate brugerflader.
Hvordan sikrer vi, at rettigheder, logning og processer forbliver konsistente mellem klient og server?
Ved at vi ikke gemmer fagregler i enkelte endepunkter eller brugerflader, men skaber et klart fagligt midtpunkt, som klient, portal og service kan anvende i fællesskab.
Læs mere om emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående faglige side, finder du der den større sammenhæng mellem arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Integration
Grænseflader, dataflows & platformsmål
Disse spørgsmål opstår som regel, når datakvalitet, sporbarhed og fremtidige platformsskift bliver vigtigere end den rene dataoverførsel fra A til B.
Grænseflader virker ofte som bisager. I virkeligheden afgør de datakvalitet, sporbarhed, platformsudskiftning og stabil drift.
Kan eksisterende grænseflader og dataflows fornyes uden Big Bang?
Ja. I mange projekter reorganiserer vi mapping, databasestier, jobs og integrationer trinvis, så de reelle processer kan fortsætte.
Håndterer I også integrationer til finansbogføring og tredjepartssystemer?
Ja. Specielt Fibu, APIs, CRM, lager, Lizenzlogik eller branchespecifikke tredjepartssystemer skal tilsluttes med ordentlig dokumentation, overvågning og faglig kontrol.
Tænker I platformsmål som Windows 11 ARM64 med i sådanne integrationsprojekter?
Ja. Nye målplatforme, native afhængigheder og fremtidige udrulningsveje hører tidligt med i samme planlægning som grænseflader og dataflowlogik.
Thema im Detail weiterlesen
Hvis du fra denne FAQ vil gå videre til den dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Delphi
Delphi til virksomhedsapplikationer
Her handler det om det grundlæggende spørgsmål: hvornår Delphi også i dag er et bevidst arkitekturvalg, og hvornår andre komponenter med fordel bør supplere eller overtage.
Når det gælder Delphi i virksomheder, er det sjældent nostalgi, men snarere spørgsmålet om, hvordan indgroet faglogik, desktopprocesser og flere målplatforme kan videreføres økonomisk forsvarligt.
Hvorfor vælger man i dag stadig bevidst Delphi?
Fordi Delphi i mange virksomhedsapplikationer udgør en stærk kombination af indgroet forretningslogik, højtydende desktopprocesser, tæt databasenærhed og kontrolleret videreudvikling.
Er Delphi kun interessant til modernisering af eksisterende systemer?
Nej. Delphi giver også mening for nye virksomhedsapplikationer, når produktive desktopforløb, rapporter, lokal integration og en fælles faglig base for flere platforme er vigtige.
Hvor ligger begrænsningerne for Delphi?
Især der, hvor et projekt primært er portal-, service- eller cloudcentreret. Så kombinerer vi bevidst Delphi med C#, REST-servere eller webkomponenter i stedet for at tvinge alt ind i ét værktøj.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
C#
C# til tjenester & portaler
Denne FAQ henvender sig til virksomheder, der ikke ser C# som et mål i sig selv, men som en stærk byggesten for portaler, API’er, integrationer og serviceorienterede arkitekturkomponenter.
For os er C# især stærk, når webportaler, API’er, tjenester, integrationer og et roligt driftsomfang står i forgrunden.
Hvornår er C# i forhold til Delphi det bedre valg?
Især når et projekt primært består af REST-API’er, portaler, back-end-tjenester, integrationer eller cloudnære driftsmodeller.
Bruger I også C# sammen med eksisterende Delphi-systemer?
Ja. Netop denne kombination er ofte fornuftig: Delphi bærer produktiv faglogik i klienten, mens C# supplerer services, portaler og API-lag på en ryddelig måde.
Hvad er typiske risici ved C#-projekter?
Ofte bygges der for hurtigt teknisk moderne uden at definere roller, faglogik, logning, deployment og reelle driftsforhold tidligt nok og klart. Netop dér griber vi ind.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Arkitektur
Layer-3-arkitektur
Layer-3 forklares ofte teoretisk. I praksis afgør denne struktur dog direkte, om nye Clients, Services, Tests og udvidelser kan tilsluttes roligt eller ender dyrt adskilte.
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på opståede monolitter, modstridende udvidelser og kostbare koblinger i dagligdagen.
Hvorfor er Layer-3 så vigtig i virksomhedsapplikationer?
Fordi først en klar adskillelse af UI, forretningslogik og dataadgang sikrer, at udvidelser, Tests, Services og nye platforme ikke fejler direkte imod monolitten.
Er Layer-3 kun relevant for store projekter?
Nej. Især mellemstore systemer drager stor fordel af det, fordi senere krav kan tilsluttes langt mere kontrolleret.
Hvad er den hyppigste fejl ved Layer-3?
At man kun tegner lagene formelt, men skjuler de egentlige regler i UI-koden eller direkte i SQL-specialveje. Så findes opbygningen kun på slides, ikke i systemet.
Thema im Detail weiterlesen
Hvis du vil skifte fra denne FAQ til den dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrunde og relaterede emner.
Delphi-Team
Delphi-udviklere fra Freiburg
Ved denne forespørgsel handler det sjældent kun om en ledig person. Ofte ligger spørgsmålet i, om en partner reelt kan overtage eksisterende systemer, faglogik, dataadgang og den tekniske retning på en holdbar måde.
Når man søger efter Delphi-udviklere, handler det sjældent kun om ledig kapacitet. Ofte drejer det sig om en robust overtagelse af eksisterende løsning, arkitektur, dataadgang og reelt fagligt ansvar.
Hvornår giver en ekstern Delphi-udvikler mening?
Især når viden om det eksisterende mangler, moderniseringen er sat i stå, eller en applikation skal fagligt videreudvikles uden at miste sin substans.
Kan I også gå ind i etablerede Delphi-applikationer?
Ja. Netop det er et fokusområde: Vi analyserer gammel kode, database, Deployment, specialtilfælde og faglige processer og bygger kontrolleret videre på dette.
Handler det kun om programmering eller også om teknisk retning?
Det handler udtrykkeligt også om retning. God Delphi-udvikling omfatter for os arkitektur, dataadgang, integrationer, REST-Services og den reelle drift.
Thema im Detail weiterlesen
Hvis du vil skifte fra denne FAQ til den dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrunde og relaterede emner.
Support
Delphi-Vedligeholdelse & Support
Vedligeholdelse lyder ofte mindre, end den er. I praksis handler det om stabile releases, synlige risici, teknisk orden og spørgsmålet om, hvordan et voksent system igen kan videreudvikles roligt.
Vedligeholdelse af voksede Delphi-systemer er mere end fejlrettelser. Den omfatter release-sikkerhed, datakonsistens, teknisk gæld og spørgsmålet om, hvordan nye krav roligt kan passe ind i det eksisterende.
Hvad hører til en god Delphi-vedligeholdelse?
Fejludredning, videreudvikling, databasevedligeholdelse, release-bistand, teknisk dokumentation og en arkitektur, der ikke unødigt gør nye krav dyrere.
Kan drift og vedligeholdelse også starte uden komplet ombygning?
Ja. Ofte begynder den med stabilisering, synliggørelse af risici og en prioriteret liste over tekniske og faglige forbedringer.
Hvordan reducerer I afhængigheden af enkeltpersoners viden?
Ved at dokumentere dataveje, komponenter, build-trin og kritisk forretningslogik struktureret og gøre implicit viden til efterprøvbar systemlogik.
Læs emnet i detaljer
Hvis I vil gå fra denne FAQ til den mere dybdegående fagartikel, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Modernisering
Delphi-modernisering
Disse svar hjælper især dér, hvor en gammel applikation fagligt stadig er stærk, men teknisk har samlet for mange bremsende elementer til at bære nye krav rent.
Det kritiske punkt ved modernisering er sjældent kun overfladen. Ofte handler det om forretningslogik, data, afhængigheder og en migrationsstrategi, der fungerer i daglig drift.
Skal en gammel Delphi-applikation fuldstændigt erstattes?
Nej. Ofte er en kontrolleret ombygning mere hensigtsmæssig: forny dataadgangen, adskil logik, suppler med services og moderniser brugergrænseflader målrettet.
Hvordan undgår man driftsforstyrrelser ved modernisering?
Gennem klare mellemfaser, rene grænseflader og en migrationssti, hvor gamle og nye dele kan eksistere kontrolleret side om side.
Kan eksisterende forretningslogik senere også overgå til services eller portaler?
Ja. Netop derfor trækker vi forretningslogik ud af UI-nær gammel kode og placerer den i en struktur, som klienter, services og API’er kan bruge fælles.
Læs emnet i detaljer
Hvis I vil gå fra denne FAQ til den mere dybdegående fagartikel, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Dataadgang
BDE-udskiftning
BDE er sjældent blot en gammel driver. Den hænger som regel sammen med historisk SQL-logik, databaseantagelser og udrulningsveje. Netop derfor besvarer vi emnet her bevidst lidt bredere.
BDE er sjældent blot en enkelt teknisk komponent. Den hænger sammen med SQL, Deployment, drivere, tegnsæt og historiske bivirkninger. Derfor betragter vi udskiftningen som et moderniseringsskridt og ikke som en komponentudskiftning.
Er et skift til FireDAC eller native drivere muligt uden komplet ombygning?
Ja, ofte i etaper. Vigtigt er det at gennemgå SQL, datatyper, transaktioner og særlige tilfælde grundigt, i stedet for blot at erstatte komponenter 1:1.
Hvorfor vedrører en BDE-udskiftning næsten altid også databasens struktur?
Fordi gamle tabeller, indekser, tegnsæt og historisk opståede SQL-stier ofte bliver synlige og bør oprydes for at sikre stabilitet og ydeevne.
Hvad opnår man konkret ved native databaseforbindelse?
Simplere Deployment, bedre vedligeholdelse, kontrollerbare forbindelser og et markant bedre fundament for services, API’er og fremtidige udvidelser.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og relaterede emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Når man anvender PostgreSQL og BDE-Ablösung mit nativer Anbindung, ønsker man som regel mere end blot en ny komponent. Ofte drejer det sig om, hvordan dataadgang, SQL, Deployment og eksisterende forretningslogik kan bringes tilbage på et bæredygtigt spor.
Med PostgreSQL og FireDAC handler det ikke kun om en ny forbindelseskomponent. Som regel er der tale om et større skridt mod mere robust SQL, bedre Deployment og kontrolleret datalagring.
Hvornår er PostgreSQL et godt valg for Delphi?
Når stabilitet, flerbrugerdrift, klare SQL-stier, åben infrastruktur og rene udvidelsesmuligheder for desktop, services eller portaler er vigtige.
Er FireDAC altid den rigtige vej?
FireDAC er ofte en meget god vej, men ikke som en blind udskiftning. Afgørende er SQL-adfærd, datatyper, transaktioner, fejlstier og det konkrete eksisterende system.
Kan BDE-, Paradox- eller gamle SQL-systemer gradvis overgå til PostgreSQL?
Ja. I mange tilfælde er en kontrolleret trinvis tilgang mere økonomisk end et hårdt brud, så længe datamodel og faglogik bliver tænkt med.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og relaterede emner.
Delphi REST
Delphi REST-API & REST-Server
Denne FAQ besvarer det typiske grundspørgsmål om, hvorvidt REST med Delphi blot er et teknisk tillæg eller en seriøs serverstrategi. Afgørende er altid, hvor godt klient, regler, data og drift holdes samlet.
REST med Delphi bliver stærk, når API’er ikke står løsrevet ved siden af den eksisterende løsning, men håndterer rettigheder, forretningslogik, datamodel og drift konsekvent.
Kan man bygge produktive REST-API’er med Delphi?
Ja. Især når den samme forretningslogik allerede lever i den eksisterende Delphi-installation, er en klart afgrænset REST-server ofte mere omkostningseffektiv end en helt ny parallel verden.
Hvornår er en REST-server at foretrække frem for direkte databaseadgang?
Så snart flere klienter, portaler, tjenester eller integrationer skal anvende de samme regler under kontrol, og direkte SQL-adgang bliver fagligt for risikabelt.
Hvordan holder I Delphi-klient og REST konsistente?
Gennem en arkitektur, hvor forretningsregler ikke forbliver skjult i formularer, men gøres fælles til brug for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybere fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Tjenester
Windows- & Linux-tjenester
Ved tjenester handler det sjældent kun om en kørende proces. Vigtigere er logging, observerbarhed, genstart, datakonsistens og det faglige spørgsmål om, hvilke dele hører hjemme i baggrunden og hvilke ikke.
Baggrundstjenester er ofte det usynlige kerne i et system. De skal køre stabilt, håndtere tilstandsskift ordentligt og passe robust ind i driften med logging, genstart og overvågning.
Hvornår har en virksomhedsapplikation brug for yderligere Windows- eller Linux-tjenester?
Altid når importer, exporter, tidsstyring, synkronisation, licenslogik eller integrationer ikke skal være bundet til en indlogget desktop-session.
Kan tjenester og REST komme fra samme arkitektur?
Ja. Netop det er ofte fornuftigt, fordi forretningslogik, datamodel og logging dermed ikke splittes op i flere tekniske øer.
Hvad er særligt vigtigt for produktive tjenester?
Klar fejlhåndtering, observerbare tilstande, genstartssikkerhed, logging, udrulning og en fagligt konsistent behandling frem for tavs baggrundsmagi.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybere fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Teknologi
Delphi Multiplatform
Denne FAQ belyser den tekniske side af multiplatformstrategien: kodebase, packaging, systemnærhed, release-processer og spørgsmålet om, hvornår flere klienter virkelig bliver økonomisk rentable.
Multiplatform fungerer kun ordentligt, hvis kodebase, datamodel, platformforskelle og udrulning planlægges bevidst. Netop dér opstår den egentlige projektværdi.
Kan den samme applikation virkelig køre på Windows, macOS og Linux?
Ja, hvis brugergrænseflade, forretningslogik, platformspecifikke forhold og release-processer ikke blandes, men struktureres klart.
Hvad er den hyppigste fejl i multiplatformsprojekter?
At tænke for sent på filsystem, udskrivning, signering, målplatforme, pakkehåndtering og UI-forskelle. Så bliver multiplatform hurtigt dyrt og inkonsekvent.
Kan services og API’er bruge den samme forretningslogik?
Ja. En god arkitektur sikrer, at ikke hver platform udvikler sin egen faglige særvej.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Serverarkitektur
REST-servere & Services
Hvis API’er og tjenester kun lyder teknisk moderne, men ikke er fagligt klart afgrænsede, bliver de hurtigt et problem. Denne FAQ sætter netop disse beslutninger i perspektiv.
Mange systemer fejler ikke på API-idéen, men fordi serverlogik senere improviseres oven på et eksisterende desktopmiljø. Vi planlægger disse dele bevidst sammen.
Hvornår har en virksomhedsapplikation brug for en REST-server?
Så snart flere klienter, portaler, mobiladgang, eksterne integrationer eller løst koblede processer kontrolleret skal bruge den samme forretningslogik.
Understøtter I også Windows- og Linux-Services?
Ja. Baggrundsprocesser, tidsstyring, synkronisering, eksporter, licenstjenester og tekniske følgesprocesser er typiske opgaver for os.
Hvordan bevares den faglige konsistens mellem klient, REST og service?
Gennem en arkitektur, hvor forretningsregler ikke er skjult i enkelte brugerflader, men forbliver fælles anvendelige og efterprøvelige.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Platform
Windows 11 ARM64
ARM64 virker for mange applikationer tidligere end forventet. Denne FAQ besvarer de typiske spørgsmål om afhængigheder, tests, installationsprogrammer og den økonomiske vurdering af ny målhardware.
ARM64 er ikke længere et eksotisk sideemne, men en reel målplatform. Den, der tager den i betragtning tidligt, undgår senere tekniske blindgyder i deployment og ved native afhængigheder.
Hvorfor bør Windows 11 ARM64 allerede tages i betragtning i dag?
Fordi nye hardwareklasser og mobile arbejdspladser i stigende grad bygger på det, og teknisk efterarbejde senere bliver betydeligt dyrere end en tidlig arkitekturbeslutning.
Hvad er særligt kritisk ved Delphi og native afhængigheder på ARM64?
Især eksterne biblioteker, database-drivere, installationsprogrammer, opsætningsprocesser og tests på reel målhardware skal tidligt afprøves.
Skal der for ARM64 udvikles et helt separat produkt?
Ikke nødvendigvis. Ofte er det tilstrækkeligt at forberede build- og deployment-pipelines ordentligt og at afkoble kritiske native afhængigheder i tide.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående faglige side, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nært beslægtede emner.
Skal en konkret projektdrøftelse følge af denne FAQ?
Så er det næste fornuftige skridt ikke endnu en samling nøgleord, men en struktureret vurdering af jeres nuværende system: Hvilken forretningslogik er til stede, hvor hæmmer den nuværende arkitektur, hvilke grænseflader er kritiske og hvilken udbygningsvej er teknisk virkelig holdbar?