Spørgsmål og svar
Oversigt over centrale FAQ
Passende ydelses- og teknologispor
Vigtige fordybninger i dette emne
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 forbliver bevidst på de respektive detaljesider. Her strukturerer vi dem yderligere som en landingside, så interesserede hurtigt kan se, hvilke emner vi virkelig mestrer inden for projektstart, ydelser, Delphi, C#, Layer-3, portaler, modernisering, dataadgang og platformstrategi.
Du kan enten gå direkte til en emneblok eller fra neden skifte til den uddybende underside. Dermed forbliver siden anvendelig både som et hurtigt indgangspunkt og som et struktureret FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbejde
Spørgsmål om en fornuftig opstart, kortlægning og tidlige arkitekturvalg.
Direkte til svarene
Ydelser
Oversigt over ydelserne
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, 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 økonomisk rentabilitet, proceslogik, roller, data og langsigtet udvidbarhed.
Direkte til svarene
Ydeevne
Multiplatform med Delphi
Spørgsmål om Windows, macOS, Linux samt senere iOS- og Android-forløb ud fra fælles forretningslogik.
Direkte til svarene
Ydeevne
Services, REST-servere & portaler
Spørgsmål om portaler, API’er, Windows- og Linux-services som en del af samme domænearkitektur.
Direkte til svarene
Integration
Grænseflader, dataflows & platformsmål
Spørgsmål om regnskabssystemer, API’er, databaseombygning, mapping, overvågning og nye målplatforme.
Direkte til svarene
Delphi
Delphi til virksomhedsapplikationer
Hvorfor Delphi fortsat kan være et stærkt valg ved vokset forretningslogik, rapporter og produktive desktopprocesser.
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 adskillelsen 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 støtte, overtagelse af bestående løsninger og teknisk ansvar i etablerede Delphi-systemer.
Direkte til svarene
Support
Delphi-Vedligeholdelse & Support
Spørgsmål om stabilisering, videreudvikling, releasesikkerhed og reduktion af enkeltmandsviden.
Direkte til svarene
Modernisering
Delphi-Modernisering
Spørgsmål om ombygningsvej, risiko, bevarelse af forretningslogik og trinvis fornyelse i drift.
Direkte til svarene
Dataadgang
BDE-Udskiftning
Spørgsmål om FireDAC, native drivere, SQL-særligheder, udrulning og nyorganisering af databasen.
Direkte til svarene
PostgreSQL
Delphi, PostgreSQL & FireDAC
Spørgsmål om PostgreSQL-migration, 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-tilpasning, fælles forretningslogik og ren serverarkitektur.
Direkte til svarene
Tjenester
Windows- & Linux-tjenester
Spørgsmål om baggrundstjenester, tidsstyring, overvågning, genstartsadfærd og klar driftsafgrænsning.
Direkte til svarene
Teknologi
Delphi Multiplatform
Spørgsmål om en 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 udrulningsveje.
Direkte til svarene
Projektstart
Projektstart, Arkitektur & Samarbejde
Mange af de første spørgsmål handler ikke om en enkelt teknologi, men om det rette udgangspunkt: Hvad bør afklares først, hvordan opstår teknisk orientering, og hvordan bliver en idé til et holdbart indledende skridt i et reelt projekt?
På startsiden dukker som regel 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 fornuftigt end hektisk nyudvikling?
Hvornår er Delphi-modernisering værd at foretrække frem for komplet nyudvikling?
Når forretningslogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte mere økonomisk end en nystart med funktionstab 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 brugergrænseflade, tjenester og dataadgang, så flere platforme kan forsynes rent.
Bygger Net-Base også REST-servere og baggrundstjenester?
Ja. Windows- og Linux-tjenester, REST-API’er, integrationslag og udrulning hører for os til arkitekturen og bliver ikke blot eftermonteret.
Hvordan starter et typisk projekt?
Som regel med en struktureret statusoptælling: mål, eksisterende systemer, database, platforme, grænseflader og driftsrisici. Deraf opstår et realistisk tilpasseligt startpunkt.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere udførlige faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Ydelser
Ydelser – Oversigt
På ydelser-siden opstår som regel de bredeste opfølgningsspørgsmål: Hvad overtager vi konkret, hvor langt rækker vores tekniske ansvar, og hvordan hænger 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 initiativ udvikler sig til et diffust stort projekt.
Overtager I også eksisterende Delphi-systemer?
Ja. Vi træder regelmæssigt ind i voksede Delphi-applikationer, analyserer det eksisterende setup, dataadgang, arkitektur og specialtilfælde og bygger kontrolleret videre derfra.
Kan REST-servere, portaler og desktop-klienter opstå ud af ét projekt?
Ja. Især ved virksomhedsapplikationer planlægger vi disse byggeklodser bevidst sammen, så den samme forretningslogik ikke splittes ud i flere specialløsninger.
Er en BDE-erstatning også mulig uden komplet udskiftning?
I mange tilfælde ja. Vi løsriver dataadgang, SQL og udrulning trinvis fra den gamle struktur og bygger en native, vedligeholdbar forbindelse.
Understøtter I også drift og videreudvikling?
Ja. Release-processer, hosting, fejlanalyse, databasevedligehold og senere udvidelser er en del af vores arbejdsfelt.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagartikel, finder du der det større perspektiv på arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Teknologier
Teknologi og arkitektur i overblik
Denne FAQ samler de typiske orienteringsspørgsmål ved teknologivalg: Hvornår er Delphi stærk, hvornår er C# den bedre komponent, og hvordan fører en ren arkitektur flere platforme, services og klienter kontrolleret sammen?
Teknologiske beslutninger skal passe til teamet, fagligheden og driften. Netop derfor afklarer vi disse spørgsmål ikke abstrakt, men altid ud fra det konkrete system.
Hvornår er Delphi hensigtsmæssigt frem for en komplet ny platform?
Når opbygget forretningslogik, ydende desktop-processer og multiplatformsmål økonomisk skal videreføres, i stedet for at udskifte substansen uforsigtigt.
Hvornår anvender I desuden C#?
Først og fremmest til portaler, web-backends, REST-services, integrationer og serviceorienterede arkitekturdele, der kan integreres godt med eksisterende desktop-systemer.
Hvor vigtig er Layer-3 i praksis?
Meget. Først den klare adskillelse af UI, forretningslogik og dataadgang gør modernisering, tests, services og fremtidige platformsudskiftninger håndterbare.
Involverer I nye platforme som Windows 11 ARM64 tidligt?
Ja. Ny målhardware og udrulningsveje vurderes tidligt, så det ikke senere udvikler sig til kostbare specialprojekter.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagartikel, finder du der det større perspektiv på arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Projekter
Projektbilleder og referencemønstre
Den, der ser på projektsiden, vil som regel forstå, hvilken type initiativer vi faktisk står for: enkeltstående værktøjer eller længerevarende systemer med drift, adgangskontrol, versionering, integrationer og reel videreudvikling.
Mange projekter lyder i første omgang forskellige og har alligevel fælles mønstre: opbygget forretningslogik, integrationer, rettigheder, versionering, driftsspørgsmål og langsigtet udvidbarhed.
Arbejder I primært på enkeltstående værktøjer eller på systemer med længere levetid?
Fokus ligger på systemer med drift, ansvar og videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Især for ældre, organisk voksede systemer planlægger vi ofte en trinvis videreudvikling, så drift og modernisering harmonerer.
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 kun udvikles, men også drives robust.
Læs videre om emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Virksomhedssoftware
Skræddersyet virksomhedssoftware & Layer-3
Disse spørgsmål opstår typisk, når standardsoftware fagligt ikke længere rækker, og en virksomhed vil vide, om et individuelt system virkelig kan bygges økonomisk fornuftigt, vedligeholdes og udbygges.
Især ved skræddersyet virksomhedssoftware drejer det sig ikke kun om enkelte skærmbilleder, men om roller, data, kontrolforløb og en arkitektur, der også senere forbliver bevægelig.
Er skræddersyet virksomhedssoftware kun meningsfuldt for meget store virksomheder?
Nej. Det er relevant altid, når standardsoftware kun kan afbilde processer med omveje, mediebrud eller dyre særregler, og den egentlige værdi ligger i ren faglogik.
Hvorfor fremhæver I Layer-3 så stærkt ved virksomhedsapplikationer?
Fordi det først er adskillelsen af UI, forretningslogik og dataadgang, der sikrer, at rapportering, nye klienter, services og fremtidige udvidelser forbliver økonomisk kontrollerbare.
Kan I også gå ind i eksisterende, vokse bestående processer?
Ja. Netop her bliver vores arbejde stærkt, fordi vi gør fagprocesser, tilgængelige data og gammel logik læsbar og udvikler deraf en bæredygtig målarkitektur.
Læs videre om emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Se detaljer om skræddersyet virksomhedssoftware & Layer-3-applikationer
Ydelser
Multiplatform med Delphi
Virksomheder spørger her typisk ikke kun efter en teknisk mulighed, men efter en holdbar strategi: Hvilke dele forbliver fælles, hvad skal håndteres platformspecifikt, og hvordan undgår man dyrt parallelt arbejde?
Multiplatform bliver først værdifuldt, når den samme faglogik forbliver kontrolleret på tværs af flere målsystemer, og platformspecifika forhold gøres synlige tidligt.
Kan man med Delphi ud over Windows også inddrage macOS, Linux, iOS og Android?
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 fra bunden.
Hvordan undgår I, at multiplatformprojekter fagligt løber fra hinanden?
Gennem en fælles kode- og arkitekturstrategi: Fagregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst kapsles.
Er det også muligt at tilføje mobile udvidelsesfaser senere?
Ja. Når arkitektur, services og grænseflader er forberedt ordentligt, kan iOS- eller Android-mål tilsluttes senere på en langt mere kontrolleret måde.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den mere detaljerede faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Ydelser
Tjenester, REST-server & portaler
Netop her skal rettigheder, dataflows, logging og faglige regler forblive samlede. Derfor behandler vi emnet ikke som en web-tilbygning, men som en ordnet udbygning af samme applikationslinje.
Portaler, REST-APIs og tjenester er kun værdifulde, hvis de fagligt ikke står ved siden af kernesystemet, men viderefører den samme data- og rollelogik konsekvent.
Udvikler I både REST-server og Windows- og Linux-tjenester?
Ja. Baggrundstjenester, APIs, importer, eksporter, portaler og teknisk driftslogik hører til vores tilbagevendende opgavebillede.
Hvornår har en virksomhedsapplikation brug for en portal?
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 mellem klient og server konsistente?
Ved ikke at skjule fagregler i enkelte endepunkter eller UI’er, men i stedet skabe en klar faglig midte, som klient, portal og tjeneste kan anvende fælles.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den mere detaljerede faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Integration
Grænseflader, dataflows & platformsmål
Disse spørgsmål opstår typisk, når datakvalitet, sporbarhed og fremtidige platformskift bliver vigtigere end den rene dataoverførsel fra A til B.
Grænseflader virker ofte som sideløbende emner. I virkeligheden afgør de datakvalitet, sporbarhed, platformsforflytning og stabil drift.
Kan eksisterende grænseflader og dataflows fornyes uden Big Bang?
Ja. I mange projekter omorganiserer vi kortlægning, databaseveje, jobs og integrationer trinvist, så reelle processer kan fortsætte.
Implementerer I også integrationer til finansbogføring og tredjepartssystemer?
Ja. Specielt Fibu, APIs, CRM, lager, licenslogik eller branchespecifikke tredjepartssystemer skal være ordentligt dokumenterede, observerbare og fagligt kontrollerbare i tilslutningen.
Tænker I platformsmål som Windows 11 ARM64 med i sådanne integrationsprojekter fra starten?
Ja. Nye målplatforme, native afhængigheder og fremtidige deploymentsveje hører tidligt ind i samme planlægning som grænseflader og dataflowlogik.
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, beslutningsårsager og tilstødende emner.
Delphi
Delphi til virksomhedsapplikationer
Dette handler om det grundlæggende spørgsmål: hvornår er Delphi også i dag et bevidst arkitekturvalg, og hvornår bør andre komponenter fornuftigt supplere eller overtage.
Når det gælder Delphi i virksomheder, handler det sjældent om nostalgi, men om, hvordan etableret faglogik, desktopprocesser og flere målplatforme kan videreføres økonomisk forsvarligt.
Hvorfor vælger I i dag stadig bevidst Delphi?
Fordi Delphi i mange virksomhedsapplikationer udgør en stærk kombination af etableret forretningslogik, højtydende desktopprocesser, tæt databaseintegration 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 grænserne for Delphi?
Især dér, hvor et projekt primært er portal-, service- eller cloudcentreret. I de tilfælde kombinerer vi Delphi bevidst med C#, REST-servere eller web-komponenter i stedet for at presse alt ind i ét værktøj.
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, beslutningsårsager og tilstødende emner.
C#
C# til Services & Portaler
Denne FAQ henvender sig til virksomheder, der ikke ser C# som et mål i sig selv, men som en stærk byggesten til portaler, API’er, integrationer og serviceorienterede arkitekturdele.
C# er for os især stærkt, når web-portaler, API’er, 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-API’er, portaler, backend-tjenester, integrationer eller cloudnære driftsmodeller.
Bruger I C# også sammen med eksisterende Delphi-systemer?
Ja. Netop denne kombination er ofte fornuftig: Delphi huser produktiv faglogik i klienten, mens C# supplerer services, portaler og API-lag.
Hvad er typiske risici ved C#-projekter?
Ofte bygges der teknisk for hurtigt moderne, uden at roller, faglogik, logning, udrulning og reelle driftsmæssige spørgsmål bliver klart afgrænset tidligt nok. Netop dér griber vi ind.
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, beslutningsårsager og tilstødende emner.
Arkitektur
Layer-3-arkitektur
Layer-3 forklares ofte teoretisk. I praksis afgør denne struktur imidlertid direkte, om nye klienter, services, tests og udvidelser kan tilslutte sig problemfrit eller ender i dyre frakoblinger.
Layer-3 er ikke et lærebogsudtryk, men en meget praktisk løsning på eksisterende monolitter, modstridende udvidelser og dyre koblinger i hverdagen.
Hvorfor er Layer-3 så vigtigt for virksomhedsapplikationer?
Fordi først en ren 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 har stor fordel af det, fordi senere krav kan tilsluttes væsentligt mere kontrolleret.
Hvad er den hyppigste fejl ved Layer-3?
At man kun tegner lagene formelt, mens de faktiske regler fortsat er skjult i UI-koden eller direkte i særlige SQL-stier. Så eksisterer opbygningen kun i præsentationer, ikke i systemet.
Læs mere om emnet i detaljer
Hvis De vil skifte fra denne FAQ til den mere dybdegående fagside, finder De der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende 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, hvorvidt en partner robust kan overtage den eksisterende kodebase, faglogik, dataadgang og den tekniske retning.
Ved søgning efter Delphi-udviklere drejer det sig sjældent kun om ledig kapacitet. Ofte handler det om en pålidelig overtagelse af eksisterende kode, arkitektur, dataadgang og ægte fagligt ansvar.
Hvornår er en ekstern Delphi-udvikler relevant?
Særligt 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 De også træde ind i etablerede Delphi-applikationer?
Ja. Det er netop et af vores fokusområder: Vi analyserer gammel kode, database, Deployment, særlige tilfælde og faglige processer og bygger derpå kontrolleret videre.
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 mere om emnet i detaljer
Hvis De vil skifte fra denne FAQ til den mere dybdegående fagside, finder De der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende 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 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 passe ind i det eksisterende.
Hvad hører til en god Delphi-vedligeholdelse?
Fejlanalyse, videreudvikling, databasevedligeholdelse, release-understøttelse, teknisk dokumentation og en arkitektur, der ikke gør nye krav unødigt dyrere.
Kan løbende support 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 vi dokumenterer dataprofiler, komponenter, build-trin og kritisk faglogik struktureret og gør implicit viden til efterprøvbar systemlogik.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybere faglige side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Modernisering
Delphi-Modernisierung
Disse svar hjælper især dér, hvor en ældre applikation fagligt stadig er stærk, men teknisk har samlet for mange bremseklodser til rent at kunne bære nye krav.
Det kritiske punkt ved modernisering er sjældent kun brugerfladen. Som regel handler det om faglogik, data, afhængigheder og en migrationsstrategi, der fungerer i daglig drift.
Skal en gammel Delphi-applikation komplet udskiftes?
Nej. Ofte er en kontrolleret ombygning mere hensigtsmæssig: forny dataadgangen, løs kobling af logik, suppler med services og moderniser brugerflader målrettet.
Hvordan undgår man driftsafbrydelse ved modernisering?
Gennem klare mellemtrin, rene grænseflader og en migrationsvej, hvor gamle og nye dele kontrolleret kan eksistere side om side.
Kan eksisterende faglogik senere også overgå til services eller portaler?
Ja. Netop derfor frigør vi forretningslogik fra UI-nær gammel kode og bringer den i en struktur, som klienter, services og API’er kan bruge fælles.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den dybere faglige side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Dataadgang
BDE-Ablösung
BDE er sjældent kun en gammel drivkraft. Den hænger som regel sammen med historisk SQL-logik, databaseantagelser og udrulningsstier. Netop derfor besvarer vi emnet her bevidst lidt bredere.
BDE er sjældent kun 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 omlægning?
Ja, ofte i etaper. Det er vigtigt at gennemgå SQL, datatyper, transaktioner og særlige tilfælde grundigt i stedet for blot at erstatte komponenter 1:1.
Hvorfor berører udskiftningen af BDE næsten altid også databasestrukturen?
Fordi gamle tabeller, indekser, tegnsæt og historisk opståede SQL-stier ofte dukker frem og bør oprydes for stabilitet og ydeevne.
Hvad opnår man konkret ved native databaseforbindelse?
Enklere Deployment, bedre vedligeholdelse, kontrollerbare forbindelser og et markant bedre fundament for Services, API’er og fremtidige udvidelser.
Læs emnet i detaljer
Hvis De fra denne FAQ ønsker at gå videre til den dybdegående fagside, finder De der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og tilstødende emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den, der anvender PostgreSQL og BDE-Ablosung mit nativer Anbindung, ønsker som regel mere end blot en ny komponent. Bag det ligger ofte spørgsmålet om, hvordan dataadgang, SQL, Deployment og eksisterende forretningslogik igen kan bringes i en bæredygtig linje.
Med PostgreSQL og FireDAC handler det ikke blot om en ny forbindelseskomponent. Ofte ligger der derimod et større skridt mod mere robust SQL, bedre Deployment og kontrolleret dataopbevaring.
Når er PostgreSQL et godt valg for Delphi?
Altid når stabilitet, drift med flere brugere, klare SQL-stier, åben infrastruktur og ren udvidelsesmulighed for Desktop, Services eller Portale 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 den konkrete bestand.
Kan BDE-, Paradox- eller gamle SQL-systemer gradvist overgå til PostgreSQL?
Ja. I mange tilfælde er en kontrolleret trinvis vej mere økonomisk end et hårdt brud, så længe datamodel og forretningslogik tænkes med.
Læs emnet i detaljer
Hvis De fra denne FAQ ønsker at gå videre til den dybdegående fagside, finder De der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og tilstødende emner.
Delphi REST
Delphi REST-API & REST-Server
Denne FAQ besvarer det typiske principspørgsmål om, hvorvidt REST med Delphi kun er et teknisk tillæg eller en seriøs serverstrategi. Afgørende er altid, hvor velordnet klient, regler, data og drift holdes sammen.
REST med Delphi bliver stærkt, når API’er ikke står løsrevet ved siden af det eksisterende system, men konsekvent bærer rettigheder, forretningslogik, datamodel og drift.
Kan man med Delphi bygge produktionsklare REST-API’er?
Ja. Især når den samme faglogik allerede lever i Delphi-bestanden, er en velafgrænset REST-server ofte mere økonomisk end et helt nyt parallelt system.
Hvornår er en REST-server at foretrække frem for direkte databaseadgang?
Når flere klienter, portaler, tjenester eller integrationer skal anvende de samme regler på en kontrolleret måde, og direkte SQL-adgang bliver fagligt for risikabel.
Hvordan holder I Delphi-klienten og REST konsistente?
Gennem en arkitektur, hvor forretningsregler ikke forbliver skjult i formularer, men gøres fælles for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Tjenester
Windows- & Linux-tjenester
Med tjenester handler det sjældent kun om en kørende proces. Vigtigere er logging, observerbarhed, genstart, datakonsistens og det faglige spørgsmål, hvilke dele der hører til i baggrunden, og hvilke der ikke gør.
Baggrundstjenester er ofte systemets usynlige kerne. De skal køre stabilt, håndtere tilstandsændringer korrekt 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.
Kan tjenester og REST komme fra samme arkitektur?
Ja. Netop det er ofte fornuftigt, fordi forretningslogik, datamodel og logging dermed ikke splittes ud i flere tekniske øer.
Hvad er særligt vigtigt for produktionsklare tjenester?
Klar fejlhåndtering, observerbare tilstande, genstartssikkerhed, logging, udrulning og en fagligt konsistent behandling i stedet for stille baggrundsmagi.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende 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 reelt bliver økonomisk rentable.
Multiplatform fungerer kun rent, hvis kodebase, datamodel, platformsforskelle 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 brugerflade, forretningslogik, platformspecifikke særheder og release-processer ikke blandes, men klart struktureres.
Hvad er den hyppigste fejl i projekter med flere platforme?
At tænke for sent på filsystem, udskrivning, signering, målplatforme, pakketering og forskelle i brugergrænsefladen. Det gør multiplatform hurtigt dyrt og inkonsistent.
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 vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Serverarkitektur
REST-Server & tjenester
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 ovenpå et eksisterende desktop-bestand. Vi planlægger disse dele bevidst sammen.
Hvornår har en virksomhedsapplikation brug for en ekstra REST-server?
Når flere klienter, portaler, mobile adgangsformer, eksterne integrationer eller afkoblede processer skal styret bruge den 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 faglig konsistens mellem klient, REST og Service?
Gennem en arkitektur, hvor forretningsregler ikke er gemt i enkelte brugerflader, men forbliver fælles anvendelige og efterprøvelige.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende 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 biproblem, men en reel målplatform. Hvis man tager den med tidligt, undgår man senere tekniske blindgyder i driftsættelsen 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å den, og teknisk efterarbejde senere bliver væsentligt 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å den faktiske målhardware bør verificeres tidligt.
Skal der for ARM64 udvikles et helt separat produkt?
Ikke nødvendigvis. Ofte er det tilstrækkeligt at forberede build- og deployment-stierne ordentligt og at afkoble kritiske native-afhængigheder i tide.
Læs emnet i detaljer
Hvis De fra denne FAQ vil skifte til den mere dybdegående faglige side, finder De der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Skal denne FAQ føre til en konkret projektgennemgang?
Så er det næste fornuftige skridt ikke endnu en samling af buzzwords, men en struktureret indplacering af Deres eksisterende systemlandskab: Hvilken faglogik er til stede, hvor bremser den aktuelle arkitektur, hvilke grænseflader er kritiske, og hvilken udbygningsvej er teknisk reelt holdbar?
Næste trin
Hvis I har et konkret spørgsmål om modernisering, API eller platform, bør vi tidligt præcist afklare den tekniske afgrænsning.
Net-Base vurderer eksisterende systemer, dataveje, grænseflader og målplatforme ikke isoleret, men i sammenhæng med domænelogik, drift og senere udbygning.
- Eksisterende tilstand, målbillede og tekniske risici vurderes samlet.
- REST, dataadgang, portaler og idrulning bliver ikke udskudt som eftertanker.
- I ser tidligt, hvilken vej der er økonomisk og driftsmæssigt holdbar.