FAQ-landingside
Centrale spørgsmål og svar om projektstart, ydelser, virksomhedssoftware, Delphi, arkitektur, portaler, services og modernisering.
Denne side samler de hyppigste spørgsmål fra vores startside, oversigtssider og faglige undersider ét sted. De kompakte FAQs bevares bevidst på de respektive detaljesider. Her organiserer vi dem yderligere som en landingside, så interessenter hurtigt kan se, hvilke emner vi inden for projektstart, ydelser, Delphi, C#, Layer-3, portaler, modernisering, dataadgang og platformstrategi faktisk behersker.
Du kan enten springe direkte til et emneafsnit eller skifte til den uddybende underside nedenfor. Dermed forbliver siden både en hurtig indgang og et struktureret FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbejde
Spørgsmål om en meningsfuld opstart, kortlægning af eksisterende tilstand og tidlige arkitekturvalg.
Direkte til svarene
Ydelser
Oversigt over ydelser
Spørgsmål om overtagelse af eksisterende systemer, modernisering, services, dataadgang og langsigtet support.
Direkte til svarene
Teknologier
Teknologi og arkitektur i overblik
Spørgsmål om Delphi, C#, Layer-3, platformvalg og den tekniske linje på tværs af flere udbygningsfaser.
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 udvidbarhed.
Direkte til svarene
Ydelse
Multiplatform med Delphi
Spørgsmål om Windows, macOS, Linux samt senere iOS- og Android-spor baseret på fælles domænelogik.
Direkte til svarene
Ydelse
Services, REST-Server & Portale
Spørgsmål om portaler, APIs, Windows- og Linux-Services som del af den samme fagarkitektur.
Direkte til svarene
Integration
Grænseflader, Datenflüsse & Plattformziele
Spørgsmål om Fibu, APIs, databaseombygning, mapping, overvågning og nye målplatforme.
Direkte til svarene
Delphi
Delphi til virksomhedsapplikationer
Hvorfor Delphi ved opbygget forretningslogik, rapporter og produktive desktop-processer fortsat kan være stærk.
Direkte til svarene
C#
C# til Services & Portale
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 direkte økonomisk relevant.
Direkte til svarene
Delphi-Team
Delphi-udviklere fra Freiburg
Spørgsmål om ekstern support, overtagelse af eksisterende systemer og teknisk ansvar i opbyggede Delphi-systemer.
Direkte til svarene
Drift
Delphi-Vedligeholdelse & Drift
Spørgsmål om stabilisering, videreudvikling, releasesikkerhed og reduktion af enkeltmandsviden.
Direkte til svarene
Modernisering
Delphi-Modernisering
Spørgsmål om migreringsvej, risiko, bevarelse af faglogik og trinvise fornyelser under løbende drift.
Direkte til svarene
Dataadgang
BDE-Afløsning
Spørgsmål om FireDAC, native drivere, SQL-særligheder, udrulning og database-omstrukturering.
Direkte til svarene
PostgreSQL
Delphi, PostgreSQL & FireDAC
Spørgsmål om PostgreSQL-migrering, native drivere, SQL-adfærd og en kontrolleret ombygning af dataadgang.
Direkte til svarene
Delphi REST
Delphi REST-API & REST-Server
Spørgsmål om REST med Delphi, API-design, fælles faglogik og ren serverarkitektur.
Direkte til svarene
Tjenester
Windows- & Linux-tjenester
Spørgsmål om baggrundstjenester, tidsstyring, monitoring, genstartadfæ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, monitoring og driftsansvar.
Direkte til svarene
Platform
Windows 11 ARM64
Spørgsmål om ny hardware, native afhængigheder, drivere, builds og udrulningsveje.
Direkte til svarene
Projektstart
Projektstart, Arkitektur & Samarbejde
Mange af de første spørgsmål drejer sig ikke om en enkelt teknologi, men om det rigtige udgangspunkt: Hvad bør man få afklaret først, hvordan opstår teknisk orientering, og hvordan bliver en idé til en holdbar indgang til et reelt projekt?
På startsiden dukker som regel de første orienteringsspørgsmål op: Hvordan igangsættes et projekt fornuftigt, hvilke arkitekturspørgsmål bør afklares tidligt, og hvornår er modernisering mere hensigtsmæssig end en forhastet nyudvikling?
Wann lohnt sich Delphi-Modernisierung statt kompletter Neuentwicklung?
Når forretningslogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte mere økonomisk end en nystart med tab af funktionalitet og højt implementeringsrisiko.
Kann dieselbe Fachlogik für Windows, macOS und Linux laufen?
Ja. Især i Delphi-projekter planlægger vi en fælles forretningslogik og adskiller brugergrænseflade, services og dataadgang, så flere platforme kan forsynes på en ren og vedligeholdelig måde.
Baut Net-Base auch REST-Server und Hintergrunddienste?
Ja. Windows- og Linux-services, REST-APIs, integrationslag og udrulning hører for os til arkitekturen og bliver ikke først efterfølgende påbygget.
Wie startet ein typisches Projekt?
Sædvanligvis med en struktureret registrering af status: mål, eksisterende systemer, database, platforme, grænseflader og driftsrisici. Deraf opstår et realistisk, tilpasset startpunkt.
Thema im Detail weiterlesen
Hvis du vil gå fra denne FAQ til den mere dybdegående faglige side, finder du der det større sammenhæng med arkitektur, eksempler, beslutningskriterier og relaterede emner.
Ydelser
Oversigt over ydelser
På ydelser-siden opstår typisk 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 i eksisterende, gennem årene opvoksede applikationer dukker ofte de samme faglige og tekniske spørgsmål op. Disse punkter afklarer vi tidligt, før et projekt udvikler sig til et diffust storprojekt.
Übernehmen Sie auch bestehende Delphi-Systeme?
Ja. Vi går regelmæssigt ind i voksede Delphi-applikationer, analyserer eksisterende komponenter, dataadgang, arkitektur og specialtilfælde og bygger derpå kontrolleret videre.
Können REST-Server, Portale und Desktop-Clients aus einem Vorhaben entstehen?
Ja. Især ved virksomhedsapplikationer planlægger vi disse byggesten bevidst sammen, så den samme forretningslogik ikke splittes op i flere specialløsninger.
Ist eine BDE-Ablösung auch ohne Komplettaustausch möglich?
I mange tilfælde ja. Vi frigør dataadgang, SQL og udrulning trinvis fra den gamle struktur og etablerer en native, vedligeholdelsesvenlig tilslutning.
Begleiten Sie auch Betrieb und Weiterentwicklung?
Ja. Udrulningsprocesser, hosting, fejlanalyse, databasevedligehold og senere udvidelser er en del af vores arbejdsområde.
Thema im Detail weiterlesen
Hvis man fra denne FAQ vil gå videre til den dybdegående faglige side, finder man dér den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og nærliggende emner.
Teknologier
Teknologi og arkitektur i oversigt
Denne FAQ samler de typiske orienteringsspørgsmål vedrørende 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, fagområdet og driften. Derfor afklarer vi disse spørgsmål ikke abstrakt, men altid ud fra det konkrete system.
Hvornår er Delphi fornuftigt frem for en komplet ny platform?
Altid når eksisterende forretningslogik, højtydende desktopprocesser og mål om flere platforme økonomisk bør videreføres i stedet for at erstatte substans uforsigtigt.
Hvornår anvendes C# yderligere?
Særligt til portaler, web-backends, REST-services, integrationer og serviceorienterede arkitekturdele, som nemt kan sammenvæves med eksisterende desktop-systemer.
Hvor vigtigt er Layer-3 i praksis?
Meget. Først den klare adskillelse af UI, forretningslogik og dataadgang gør modernisering, tests, services og kommende platformsskift håndterbare.
Medtænkes nye platforme som Windows 11 ARM64 tidligt?
Ja. Ny målhardware og deploymentsveje vurderes tidligt, så det senere ikke udvikler sig til kostbare særprojekter.
Læs emnet i detaljen
Hvis man fra denne FAQ vil gå videre til den dybdegående faglige side, finder man dér den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og nærliggende emner.
Projekter
Projektbilleder og referencemønstre
Den, der ser på projektsiden, vil som regel forstå, hvilken type projekter vi faktisk understøtter: engangs‑værktøjer eller længerevarende systemer med drift, rettighedskoncepter, versionering, integrationer og reel videreudvikling.
Mange projekter virker i starten forskellige, men har alligevel fælles mønstre: opbygget forretningslogik, integrationer, rettigheder, versionering, driftsrelaterede spørgsmål og langsigtet udvidelsesmulighed.
Arbejdes der oftere med engangs‑enkeltværktøjer eller med længerevarende systemer?
Fokus ligger på systemer med driftstid, ansvar og videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Især for systemer, der er vokset over lang tid, planlægger vi ofte en trinvis videreudvikling, så drift og modernisering passer sammen.
Er Hosting og teknisk drift en del af jeres arbejde?
Ja. Release, Hosting, Monitoring og driftsansvar indgår i vores projektplanlægning, så den færdige løsning ikke blot udvikles, men også kan drives driftsmæssigt bæredygtigt.
Læs mere om 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, begrundelser for beslutninger og tilstødende emner.
Virksomhedssoftware
Skræddersyet virksomhedssoftware & Layer-3
Disse spørgsmål opstår typisk, når standardsoftware fagligt ikke længere slår til, og en virksomhed vil vide, om et individuelt system virkelig kan bygges økonomisk, vedligeholdeligt og med mulighed for videreudvikling.
Det handler ikke kun om enkelte skærmbilleder, men om roller, data, revisionsspor og en arkitektur, der også senere forbliver fleksibel.
Er skræddersyet virksomhedssoftware kun relevant for meget store virksomheder?
Nej. Det kan betale sig, når standardsoftware kun kan afbilde processer med omveje, mediebrud eller dyre særregler, og den egentlige værdi ligger i ren faglogik.
Hvorfor lægger I så stor vægt på Layer-3 i virksomhedsapplikationer?
Fordi først adskillelsen af UI, forretningslogik og dataadgang sikrer, at rapportering, nye klienter, services og fremtidige udvidelser forbliver økonomisk kontrollerbare.
Kan I også tage fat i eksisterende, historisk voksede processer?
Ja. Særligt her bliver vores arbejde stærkt, fordi vi gør fagprocesser, eksisterende data og gammel logik læsbar og derudfra udvikler en bæredygtig målarkitektur.
Læs mere om 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, begrundelser for beslutninger og tilstødende emner.
Se skræddersyet virksomhedssoftware og Layer-3-applikationer i detaljer
Ydelser
Multiplatform med Delphi
Virksomheder spørger her som regel ikke kun om en teknisk mulighed, men om en robust strategi: Hvilke dele forbliver fælles, hvad må håndteres platformspecifikt, og hvordan undgår man dyrt paralleludviklingsarbejde?
Multiplatform bliver først værdifuld, når den samme faglogik forbliver kontrolleret fælles på tværs af flere målplatforme, og platformspecifikke forhold synliggøres tidligt.
Kan man med Delphi ud over Windows også inkludere macOS, Linux, iOS og Android?
Ja. Afhængigt af projektmål planlægger vi desktopmål, mobile brugerflader og servernære komponenter ud fra en fælles faglig linje, i stedet for at genopbygge den faglige logik for hver platform.
Hvordan undgår I, at multiplatformprojekter fagligt afviger?
Gennem en fælles kode- og arkitekturstrategi: fagregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst kapsles ind.
Er mobile udbygninger også mulige senere?
Ja. Hvis arkitektur, services og grænseflader er korrekt forberedt, kan iOS- eller Android-mål senere kobles på i langt mere kontrolleret omfang.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og beslægtede emner.
Ydelse
Services, REST-Server & Portale
Især her skal rettigheder, dataflows, logging og faglige regler hænge sammen. Derfor behandler vi emnet ikke som en web-påbygning, men som en ordnet udbygning af samme applikationslinie.
Portaler, REST-APIs og tjenester sælger sig kun godt, hvis de fagligt ikke står ved siden af kernesystemet, men viderefører den samme data- og rollelogik rent.
Udvikler I både REST-server samt Windows- og Linux-services?
Ja. Baggrundstjenester, APIs, importer, eksporter, portaler og teknisk driftslogik er blandt vores tilbagevendende opgaver.
Hvornår har en virksomhedsapplikation desuden brug for et portal?
Altid når kunder, partnere eller interne roller skal have kontrolleret adgang til de samme processer, uden at faglige regler duplikeres i separate brugerflader.
Hvordan forbliver rettigheder, logging og processer konsistente mellem klient og server?
Ved ikke at skjule fagregler i enkelte endpoints eller UI’er, men ved at skabe en klar faglig midte, som klient, portal og service kan bruge fælles.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og beslægtede emner.
Integration
Grænseflader, dataflows & platformmål
Disse spørgsmål opstår som regel, når datakvalitet, sporbarhed og fremtidige platformsskift bliver vigtigere end ren datatransfer fra A til B.
Grænseflader virker ofte som sideløbende emner. I virkeligheden afgør de datakvalitet, sporbarhed, platformsskift og stabil drift.
Kan eksisterende grænseflader og dataflows fornyes uden Big Bang?
Ja. I mange projekter omlægger vi mapping, databasestier, jobs og integrationer trinvis, så de faktiske processer kan fortsætte.
Står I også for tilslutning af finansbogføring og tredjepartssystemer?
Ja. Især finansbogføring, APIs, CRM, lager, licenslogik eller branchespecifikke tredjepartssystemer skal tilsluttes med klar dokumentation, observerbarhed og faglig kontrol.
Tænker I platformmå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.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybdegående fagside, finder du der den bredere sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Delphi
Delphi til virksomhedsapplikationer
Dette handler om principspørgsmålet, hvornår Delphi også i dag er et bevidst arkitekturvalg, og hvornår andre komponenter fornuftigt bør supplere eller overtage.
Med Delphi handler det i virksomheder sjældent om nostalgi, men om, hvordan etableret faglogik, desktop-processer og flere målplatforme kan videreføres økonomisk forsvarligt.
Hvorfor satses der i dag stadig bevidst på Delphi?
Fordi Delphi i mange virksomhedsapplikationer tilbyder en stærk kombination af etableret forretningslogik, performante desktop-processer, nærhed til databasen og kontrollerbar videreudvikling.
Er Delphi kun interessant til modernisering af eksisterende systemer?
Nej. Delphi er også relevant for nye virksomhedsapplikationer, når produktive desktop-arbejdsgange, rapportering, lokal integration og et fælles fagligt grundlag for flere platforme er vigtige.
Hvor ligger grænserne for Delphi?
Især dér, 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 presse alt ind i ét værktøj.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybdegående fagside, finder du der den bredere sammenhæng med arkitektur, eksempler, beslutningsbegrundelser 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 byggeblok til portaler, APIs, integrationer og serviceorienterede arkitekturdele.
C# er for os især stærk, når webportaler, APIs, tjenester, integrationer og en rolig driftsafgrænsning er i fokus.
Hvornår er C# i forhold til Delphi det bedre valg?
Især når et projekt primært består af REST-APIs, portaler, backend-tjenester, integrationer eller cloudnære driftsmodeller.
Bruges C# også sammen med eksisterende Delphi-systemer?
Ja. Netop denne kombination er ofte fornuftig: Delphi bærer produktiv faglogik i klienten, mens C# services, portaler og API-lag ordentligt supplerer.
Hvad er typiske risici ved C#-projekter?
Ofte bygges der teknisk for hurtigt moderne løsninger uden at adskille roller, faglogik, logging, deployment og reelle driftsforhold tidligt og tydeligt nok. Netop her sætter vi ind.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den dybdegående fagside, finder du der den bredere sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Arkitektur
Layer-3-arkitektur
Layer-3 forklares ofte teoretisk. I praksis afgør denne struktur dog direkte, om nye klienter, services, tests og udvidelser kan koble på uhindret eller ender i dyre afhængigheder.
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på arvede monolitter, modstridende udvidelser og dyre koblinger i dagligdagen.
Hvorfor er Layer-3 så vigtig i virksomhedssystemer?
Fordi først den klare adskillelse af UI, forretningslogik og dataadgang sikrer, at udvidelser, tests, services og nye platforme ikke fejler direkte på monolitten.
Er Layer-3 kun relevant for store projekter?
Nej. Især mellemstore systemer drager stor fordel, fordi efterfølgende krav kan tilsluttes langt mere kontrolleret.
Hvad er den hyppigste fejl ved Layer-3?
At man kun skitserer lagene formelt, mens de egentlige regler fortsat er skjult i UI-koden eller direkte i særlige SQL-stier. Så findes opbygningen kun på slides, ikke i systemet.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Delphi-Team
Delphi-udviklere fra Freiburg
Ved denne forespørgsel handler det sjældent kun om en tilgængelig person. Ofte drejer det sig om spørgsmålet, om en partner kan overtage den eksisterende kodebase, faglogik, dataadgang og den tekniske retning på en pålidelig måde.
Ved søgning efter Delphi-udviklere handler det sjældent kun om ledig kapacitet. Ofte drejer det sig om en pålidelig overtagelse af eksisterende kodebase, arkitektur, dataadgang og reelt fagligt ansvar.
Hvornår er en ekstern Delphi-udvikler relevant?
Især når viden om det eksisterende mangler, moderniseringen er gået i stå, eller en applikation skal videreudvikles fagligt uden at miste sin substans.
Kan I også træde ind i etablerede Delphi-applikationer?
Ja. Det er netop et fokusområde: Vi analyserer eksisterende kode, database, deployment, særlige tilfælde og faglige processer og bygger kontrolleret videre derpå.
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.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Vedligeholdelse
Delphi-vedligeholdelse & support
Vedligeholdelse lyder ofte mindre, end den er. I praksis drejer det sig om stabile Releases, synlige risici, teknisk orden og spørgsmålet om, hvordan et voksent system igen kan videreudvikles roligt.
Vedligeholdelse er for voksede Delphi-systemer mere end Bugfixing. Den omfatter Release-sikkerhed, datakonsistens, teknisk gæld og spørgsmålet om, hvordan nye krav roligt kan integreres i det eksisterende.
Hvad hører til en god Delphi-vedligeholdelse?
Fejl-analyse, videreudvikling, databasevedligehold, Release-begledning, teknisk dokumentation og en arkitektur, der ikke gør nye krav automatisk dyrere.
Kan vedligeholdelse starte uden en 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 vi struktureret dokumenterer dataveje, komponenter, build-trin og kritisk forretningslogik og gør implicit viden til efterprøvbar systemlogik.
Læs emnet i detaljer
Hvis I vil gå fra denne FAQ til den mere dybdegående fagside, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og beslægtede emner.
Modernisering
Delphi-Modernisering
Disse svar hjælper især der, hvor en ældre applikation fagligt stadig er stærk, men teknisk har samlet for mange flaskehalse til sikkert at bære nye krav.
Det kritiske punkt ved modernisering er sjældent kun brugergrænsefladen. Som regel handler det om forretningslogik, data, afhængigheder og en migrationsstrategi, der fungerer i daglig drift.
Skal en gammel Delphi-applikation helt udskiftes?
Nej. Ofte er en kontrolleret ombygning mere hensigtsmæssig: forny dataadgang, løsne logikken, supplere med Services og modernisere grænseflader målrettet.
Hvordan undgår man driftsafbrydelse ved modernisering?
Gennem klare mellemfaser, rene Schnittstellen og en migrationssti, hvor gamle og nye dele kontrolleret kan eksistere side om side.
Kan eksisterende forretningslogik senere også overgå til Services eller Portale?
Ja. Netop derfor frigør vi forretningslogik fra UI-nær legacy-kode og bringer den i en struktur, som Clients, Services og APIs kan bruge fælles.
Læs emnet i detaljer
Hvis I vil gå fra denne FAQ til den mere dybdegående fagside, finder I der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og beslægtede emner.
Dataadgang
BDE-Afløsning
BDE er sjældent blot en gammel driver. Den hænger som regel sammen med historisk SQL-logik, databaseantagelser og Deployment-pathed. Netop derfor besvarer vi emnet her bevidst noget bredere.
Den BDE er sjældent kun en enkelt teknisk komponent. Den hænger sammen med SQL, Deployment, drivere, tegnsæt og historiske sideeffekter. Derfor ser vi udskiftningen som et moderniseringstrin og ikke som en ren komponentudskiftning.
Er en overgang til FireDAC eller native drivere mulig uden komplet ombygning?
Ja, ofte i etaper. Vigtigt er, at SQL, datatyper, transaktioner og særlige tilfælde gennemgås grundigt, i stedet for blot at erstatte komponenter 1:1.
Hvorfor berører BDE-udskiftningen næsten altid også databasestrukturen?
Fordi det ofte afdækker gamle tabeller, indekser, tegnsæt og historisk opståede SQL-veje, som bør ryddes op i af hensyn til stabilitet og performance.
Hvad opnår man konkret ved native databaseforbindelse?
Enklere Deployment, bedre vedligeholdelse, kontrollerbare forbindelser og et markant bedre grundlag for services, API’er og fremtidige udvidelser.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nærliggende emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den, der bruger PostgreSQL og BDE-Ablösung mit nativer Anbindung, vil som regel have mere end bare en ny komponent. Bag det ligger ofte spørgsmålet om, hvordan dataadgang, SQL, Deployment og eksisterende forretningslogik igen kan bringes ind i en holdbar linje.
Med PostgreSQL og FireDAC handler det ikke kun om en ny forbindelseskomponent. Ofte er der tale om et større skridt mod et mere robust SQL, bedre Deployment og kontrolleret datastyring.
Hvornår er PostgreSQL et godt valg for Delphi?
Når stabilitet, flerbrugerdrift, klare SQL-stier, åben infrastruktur og ren udvidelsesmulighed for desktopapplikationer, services eller portaler er vigtige.
Er FireDAC altid den rigtige vej?
FireDAC er ofte en meget god vej, men ikke som blind udskiftning. Afgørende er SQL-adfærd, datatyper, transaktioner, fejlforløb 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 vej mere økonomisk end et brat brud, så længe datamodel og forretningslogik indtænkes korrekt.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nærliggende emner.
Delphi REST
Delphi REST-API & REST-Server
Denne FAQ besvarer det typiske grundlæggende spørgsmål om, hvorvidt REST med Delphi kun er et teknisk tillæg eller en seriøs serverstrategi. Afgørende er altid, hvor godt klient, regler, data og drift holdes sammen.
REST med Delphi bliver stærkt, når API’er ikke fungerer isoleret ved siden af det eksisterende system, men i stedet bærer rettigheder, forretningslogik, datamodel og drift med sig.
Kan man bygge produktive REST-API’er med Delphi?
Ja. Især når den samme faglogik allerede lever i Delphi-bestanden, er en velafgrænset REST-server ofte mere økonomisk end en fuldstændig ny parallel verden.
Hvornår er en REST-server at foretrække frem for direkte databaseadgang?
Så snart flere klienter, portaler, tjenester eller integrationer kontrolleret skal anvende de samme regler, og direkte SQL-adgang bliver fagligt for risikabel.
Hvordan holder I Delphi-clienten og REST konsistente?
Gennem en arkitektur hvor forretningsregler ikke forbliver skjult i formularer, men bliver fælles tilgængelige for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Tjenester
Windows- & Linux-Services
Når det gælder Services, handler det sjældent kun om en kørende proces. Vigtigere er logning, observabilitet, genstart, datakonsistens og det faglige spørgsmål om, hvilke dele der hører hjemme i baggrunden, og hvilke der ikke gør.
Baggrundstjenester er ofte systemets usynlige kerne. De skal køre stabilt, håndtere tilstandsskift ordentligt og med logning, genstart og overvågning passe robust ind i driften.
Hvornår har en virksomhedsanvendelse brug for yderligere Windows- eller Linux-Services?
Altid når importer, eksport, tidsstyring, synkronisering, licenslogik eller integrationer ikke bør være bundet til en indlogget desktop.
Kan Services og REST komme fra samme arkitektur?
Ja. Netop det er ofte fornuftigt, fordi forretningslogik, datamodel og logning dermed ikke splittes op i flere tekniske øer.
Hvad er særligt vigtigt for produktive Services?
Klar fejlhåndtering, observerbare tilstande, genstartssikkerhed, logning, deployment og en fagligt konsistent behandling i stedet for stille baggrundsmagi.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Teknologi
Delphi Multiplatform
Denne FAQ belyser den tekniske side af multiplatform-strategien: kodebase, Packaging, systemnærhed, release-processer og spørgsmålet om, hvornår flere klienter virkelig bliver økonomisk fordelagtige.
Multiplatform fungerer kun ordentligt, når kodebase, datamodel, platformforskelle og Deployment bevidst planlægges. 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 udgivelsesprocesser ikke blandes, men struktureres klart.
Hvad er den hyppigste fejl i projekter med flere platforme?
At overveje filsystem, udskrivning, signering, målplatforme, pakning og UI-forskelle for sent. Så bliver udvikling for flere platforme hurtigt dyr 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ærtilpasning.
Læs emnet i detaljer
Hvis du fra denne FAQ går videre til den dybdegående fagside, finder du der det større perspektiv med arkitektur, eksempler, beslutningsgrundlag og nært 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 kontekst.
Mange systemer fejler ikke på API-idéen, men på, at serverlogik senere improviseres og hæftes på et eksisterende desktop-system. Vi planlægger disse dele bevidst sammen.
Hvornår har en virksomhedsapplikation desuden brug for en REST-server?
Så snart flere klienter, portaler, mobil adgang, eksterne integrationer eller løst koblede processer skal kontrolleret bruge samme forretningslogik.
Understøtter I også Windows- og Linux-services?
Ja. Baggrundsprocesser, tidsstyring, synkronisering, eksporter, licenstjenester og tekniske følgesprocesser hører til vores typiske opgaver.
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 går videre til den dybdegående fagside, finder du der det større perspektiv med arkitektur, eksempler, beslutningsgrundlag og nært beslægtede emner.
Platform
Windows 11 ARM64
ARM64 påvirker 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 sidespor, men en reel målplatform. Den, der tænker den ind tidligt, undgår senere tekniske blindgyder ved udrulning 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 satser 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, databasedrivere, installationsprogrammer, opsætningsprocesser og tests på den faktiske målhardware skal afprøves tidligt.
Skal der for ARM64 udvikles et helt separat produkt?
Ikke nødvendigvis. Ofte er det tilstrækkeligt at forberede build- og deployment-stierne grundigt og at afkoble kritiske native afhængigheder i god tid.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Skal en FAQ overgå til en konkret projektgennemgang?
Så er det næste fornuftige skridt ikke en yderligere samling af nøgleord, men en struktureret indplacering af jeres eksisterende beholdning: Hvilken faglogik er til stede, hvor bremser den aktuelle arkitektur, hvilke grænseflader er kritiske, og hvilken udbygningsvej er teknisk virkelig bæredygtig?