Overblik
FAQ i overblik
FAQ-landingpage
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 forside, oversigtssiderne og de faglige undersider på ét sted. De kompakte FAQs bliver bevidst ved med at ligge på de respektive detaljesider. Her indrammer vi dem desuden som en landingpage, så interesserede hurtigt kan se, hvilke emner vi reelt behersker inden for projektstart, ydelser, Delphi, C#, Layer-3, portaler, modernisering, dataadgang og platformstrategi.
Du kan enten springe direkte til en emneblok eller nederst skifte til den uddybende underside for hvert punkt. Dermed kan siden bruges både som hurtig indgang og som struktureret FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbejde
Spørgsmål om en meningsfuld start, om statusafdækning og om tidlige arkitekturbeslutninger.
Direkte til svarene
Ydelser
Ydelser i overblik
Spørgsmål om overtagelse af eksisterende løsning, modernisering, services, dataadgang og langsigtet drift og vedligehold.
Direkte til svarene
Teknologier
Teknologi og arkitektur i overblik
Spørgsmål om Delphi, C#, Layer-3, valg af platform og den tekniske linje på tværs af flere udbygningstrin.
Direkte til svarene
Projekter
Projektbilleder og referencemønstre
Spørgsmål om projektstørrelse, driftsansvar, hosting, produktlogik og systemer, der bærer over længere tid.
Direkte til svarene
Virksomhedssoftware
Individuel virksomhedssoftware & Layer-3
Spørgsmål om økonomisk bæredygtighed, 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 ud fra fælles faglogik.
Direkte til svarene
Ydeevne
Services, REST-servere & portaler
Spørgsmål om portaler, API’er, Windows- og Linux-services som en del af den samme fagarkitektur.
Direkte til svarene
Integration
Grænseflader, datastrømme & platformsmål
Spørgsmål om finansbogholderi, API’er, ombygning af databasen, mapping, overvågning og nye målplatforme.
Direkte til svarene
Delphi
Delphi til virksomhedsapplikationer
Hvorfor Delphi fortsat kan være stærk ved moden business-logik, rapporter og produktive desktop-processer.
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 adskillelsen af UI, business-logik 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 eksisterende systemer og teknisk ansvar i voksede Delphi-systemer.
Direkte til svarene
Drift
Delphi-vedligeholdelse & drift
Spørgsmål om stabilisering, videreudvikling, release-sikkerhed og reduktion af personafhængig viden.
Direkte til svarene
Modernisering
Delphi-modernisering
Spørgsmål om ombygningsforløb, risiko, bevarelse af forretningslogik og trinvis fornyelse i løbende drift.
Direkte til svarene
Dataadgang
BDE-udfasning
Spørgsmål om FireDAC, native drivere, SQL-særtræk, 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-tilskæring, fælles forretningslogik og ren serverarkitektur.
Direkte til svarene
Services
Windows- & Linux-services
Spørgsmål om baggrundsservices, tidsstyring, overvågning, genstartsadfærd og et rent driftsdesign.
Direkte til svarene
Teknologi
Delphi multiplatform
Spørgsmål om en fælles kodebase til Windows, macOS og Linux med kontrollerede platformgrænser.
Direkte til svarene
Serverarkitektur
REST-server & services
Spørgsmål om API’er, Windows- og Linux-services, serverlogik, overvågning og driftsansvar.
Direkte til svarene
Platform
Windows 11 ARM64
Spørgsmål om ny hardware, native afhængigheder, drivere, builds og udrulningsforløb.
Direkte til svarene
Projektstart
Projektstart, arkitektur & samarbejde
Mange indledende spørgsmål handler ikke om en enkelt teknologi, men om det rigtige udgangspunkt: Hvad bør man afklare først, hvordan opstår teknisk orientering, og hvordan bliver en idé til en robust indgang til et reelt projekt?
På forsiden dukker de første orienteringsspørgsmål typisk op: Hvordan starter man et initiativ fornuftigt, hvilke arkitekturspørgsmål bør man afklare tidligt, og hvornår kan modernisering betale sig frem for hektisk nyudvikling?
Hvornår kan Delphi-modernisering betale sig frem for komplet nyudvikling?
Når faglogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte mere økonomisk end en ny start med funktionstab og høj indføringsrisiko.
Kan den samme faglogik køre til Windows, macOS og Linux?
Ja. Netop i Delphi-projekter planlægger vi fælles business-logik og adskiller brugerflade, services og dataadgang, så flere platforme kan understøttes rent.
Bygger Net-Base også REST-servere og baggrundstjenester?
Ja. Windows- og Linux-services, REST-API’er, integrationslag og deployment hører for os til arkitekturen og bliver ikke først bygget på efterfølgende.
Hvordan starter et typisk projekt?
Som regel med en struktureret statusafdækning: mål, eksisterende systemer, database, platforme, snitflader og driftsrisici. Heraf opstår et realistisk afgrænseligt udgangspunkt.
Læs emnet i dybden
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.
Ydelser
Overblik over ydelser
På ydelsessiden opstår typisk de bredeste opfølgende spørgsmål: Hvad påtager vi os konkret, hvor langt rækker vores tekniske ansvar, og hvordan griber modernisering, integrationer, drift og videreudvikling ind i hinanden?
Især ved systemer, der er vokset over tid, dukker ofte de samme faglige og tekniske spørgsmål op. Disse punkter afklarer vi tidligt, før et initiativ bliver til et diffust storprojekt.
Overtager I også eksisterende Delphi-systemer?
Ja. Vi går regelmæssigt ind i Delphi-applikationer, der er vokset over tid, analyserer eksisterende løsning, dataadgang, arkitektur og særtilfælde og bygger kontrolleret videre derfra.
Kan REST-servere, portaler og desktop-klienter opstå ud fra ét initiativ?
Ja. Især ved virksomhedsapplikationer planlægger vi disse byggesten bevidst sammen, så den samme business-logik ikke løber ud i flere særskilte løsninger.
Er en udfasning af BDE også mulig uden komplet udskiftning?
I mange tilfælde ja. Vi frigør dataadgang, SQL og deployment trin for trin fra den gamle struktur og bygger en native, vedligeholdbar tilkobling op.
Varetager I også drift og videreudvikling?
Ja. Release-processer, hosting, fejlanalyse, databasepleje og senere udvidelser er en del af vores arbejdsbillede.
Læs emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Teknologier
Teknologi og arkitektur i overblik
Denne FAQ samler de typiske orienteringsspørgsmål om teknologivalg: Hvornår er Delphi stærk, hvornår er C# den bedre byggesten, og hvordan samler en ren arkitektur flere platforme, services og clients kontrolleret?
Teknologivalg skal passe til teamet, domænet og driften. Netop derfor afklarer vi ikke disse spørgsmål abstrakt, men altid på det konkrete system.
Hvornår giver Delphi mening i forhold til en komplet ny platform?
Altid når opbygget domænelogik, performante desktop-processer og multiplatform-mål skal videreføres økonomisk, frem for at erstatte substans letsindigt.
Hvornår bruger I desuden C#?
Især til portaler, web-backends, REST-services, integrationer og serviceorienterede arkitekturdele, som kan kobles tæt sammen med eksisterende desktop-systemer.
Hvor vigtig er Layer-3 i praksis?
Meget. Først den rene adskillelse af UI, forretningslogik og dataadgang gør modernisering, tests, services og fremtidige platforms-skift håndterbare.
Tænker I nye platforme som Windows 11 ARM64 ind tidligt?
Ja. Nyt mål-hardware og deployment-veje vurderes tidligt, så de senere ikke bliver til omkostningstunge særprojekter.
Læs mere om emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Projekter
Projektbilleder og referencemønstre
Den, der kigger på projektsiden, vil som regel forstå, hvilken type initiativer vi reelt kan bære: engangsværktøjer eller mere langtidsholdbare systemer med drift, rettighedskoncept, versioner, integrationer og reel videreudvikling.
Mange initiativer lyder i starten forskellige, men har alligevel fælles mønstre: opbygget domænelogik, integrationer, rettigheder, versioner, driftsforhold og langsigtet udvidbarhed.
Arbejder I primært med engangs-enkeltværktøjer eller med systemer, der bærer længere?
Tyngdepunktet ligger på systemer med runtime, ansvar og videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Især ved systemer, der er vokset over længere tid, planlægger vi ofte en trinvist videreudvikling, så drift og modernisering passer sammen.
Er hosting og teknisk drift en del af jeres arbejde?
Ja. Release, hosting, overvågning og driftsansvar indgår i vores projektplanlægning, så den færdige løsning ikke kun udvikles, men også kan drives robust.
Læs videre om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fag-side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Virksomhedssoftware
Individuel 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, vedligeholdbart og udbygningsegnet.
Netop ved individuel virksomhedssoftware handler det ikke kun om enkelte skærmbilleder, men om roller, data, kontrolspor og en arkitektur, der også senere forbliver fleksibel.
Er individuel virksomhedssoftware kun fornuftig for meget store virksomheder?
Nej. Den kan betale sig, når standardsoftware kun kan afbilde processer via omveje, mediebrud eller dyre særregler, og den egentlige værdi ligger i ren domænelogik.
Hvorfor fremhæver I Layer-3 så stærkt ved virksomhedsapplikationer?
Fordi først adskillelsen af UI, forretningslogik og dataadgang sikrer, at rapportering, nye clients, services og fremtidige udvidelser forbliver økonomisk kontrollerbare.
Kan I også gå ind i voksede eksisterende processer?
Ja. Netop dér bliver vores arbejde stærkt, fordi vi først gør fagprocesser, eksisterende data og legacy-logik læsbare og derfra udvikler en bæredygtig målarkitektur.
Læs videre om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fag-side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Se Individuel virksomhedssoftware & Layer-3-applikationer i detaljer
Ydelse
Multiplatform med Delphi
På dette sted spørger virksomheder som regel ikke kun til en teknisk mulighed, men til en robust strategi: Hvilke dele forbliver fælles, hvad skal håndteres platformspecifikt, og hvordan undgår man, at det bliver et dyrt parallelbyggeri?
Multiplatform bliver først værdifuldt, når den samme domænelogik forbliver kontrolleret samlet på tværs af flere målplatforme, og platformsærligheder gøres synlige tidligt.
Kan man med Delphi ud over Windows også tænke macOS, Linux, iOS og Android med?
Ja. Afhængigt af projektmålet 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 på ny.
Hvordan undgår I, at multiplatform-projekter fagligt løber fra hinanden?
Med en fælles kode- og arkitekturstrategi: Forretningsregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst kapsles.
Er mobile udbygningstrin også muligt senere?
Ja. Hvis arkitektur, services og snitflader er forberedt rent, kan iOS- eller Android-mål kobles på senere langt mere kontrolleret.
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.
Ydelse
Services, REST-servere & portaler
Især her skal rettigheder, dataflows, logging og faglige regler hænge sammen. Derfor behandler vi ikke emnet som en web-tilbygning, men som en struktureret udbygning af samme applikationslinje.
Portaler, REST-API’er og tjenester sælger kun godt, når de fagligt ikke står ved siden af kernesystemet, men rent viderefører den samme data- og rollelogik.
Udvikler I både REST-servere samt Windows- og Linux-services?
Ja. Baggrundstjenester, API’er, importer, exporter, portaler og teknisk driftslogik hører til vores tilbagevendende opgavebilleder.
Hvornår har en virksomhedsapplikation desuden brug for en portal?
Altid når kunder, partnere eller interne roller kontrolleret skal have adgang til de samme processer, uden at man duplikerer faglige regler i adskilte brugerflader.
Hvordan forbliver rettigheder, logging og processer konsistente mellem klient og server?
Ved at vi ikke gemmer forretningsregler i enkelte endpoints eller UI’er, men skaber en klar faglig kerne, som klient, portal og service kan bruge fælles.
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.
Integration
Snitflader, dataflows & platformsmål
Disse spørgsmål kommer typisk, når datakvalitet, sporbarhed og fremtidige platformsift bliver vigtigere end den rene dataoverførsel fra A til B.
Snitflader virker ofte som sidetemaer. I virkeligheden afgør de datakvalitet, sporbarhed, platformsift og stabil drift.
Kan eksisterende snitflader og dataflows fornyes uden Big Bang?
Ja. I mange projekter reorganiserer vi mapping, databaseveje, jobs og integrationer trinvis, så reelle processer kan fortsætte.
Overtager I også integrationer til finansbogholderi og tredjepartssystemer?
Ja. Især Fibu, API’er, CRM, lager, licenslogik eller branchespecifikke tredjepartssystemer skal tilkobles med ren dokumentation, observerbarhed og faglig kontrol.
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 deployment-veje hører tidligt ind i samme planlægning som snitflader og dataflow-logik.
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 tilgrænsende emner.
Delphi
Delphi til virksomhedsapplikationer
Her handler det om det grundlæggende spørgsmål, hvornår Delphi også i dag stadig er en bevidst arkitekturbeslutning, og hvornår andre byggesten giver mening at supplere eller overtage.
Med Delphi handler det i virksomheder sjældent om nostalgi, men om spørgsmålet, hvordan voksende faglogik, desktop-processer og flere målplatforme kan videreføres økonomisk og arkitektonisk rent.
Hvorfor satser I stadig bevidst på Delphi i dag?
Fordi Delphi i mange virksomhedsapplikationer tilbyder en stærk kombination af opvokset business-logik, performante desktop-processer, databasenærhed og kontrollerbar videreudvikling.
Er Delphi kun interessant til modernisering af eksisterende løsninger?
Nej. Delphi er også relevant til nye virksomhedsapplikationer, når produktive desktop-forløb, rapporter, lokal integration og en fælles faglig base til flere platforme er vigtige.
Hvor ligger grænserne for Delphi?
Frem for alt dér, hvor et initiativ primært er portal-, service- eller cloudcentreret. Så kombinerer vi Delphi bevidst med C#, REST-servere eller web-byggesten i stedet for at tvinge alt ind i ét værktøj.
Læs mere om 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 tilgrænsende 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.
For os er C# især stærk, når webportaler, API’er, tjenester, integrationer og et roligt driftsmæssigt snit er i fokus.
Hvornår er C# det bedre valg end Delphi?
Frem for alt, 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 giver ofte mening: Delphi bærer produktiv faglogik i klienten, mens C# supplerer services, portaler og API-lag rent.
Hvad er typiske risici i C#-projekter?
Ofte bygges der for hurtigt teknisk moderne, uden at roller, faglogik, logging, deployment og reelle driftsforhold bliver skåret rent tidligt nok. Det er præcis dér, vi sætter ind.
Læs mere om 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 tilgrænsende emner.
Arkitektur
Layer-3-arkitektur
Layer-3 forklares ofte teoretisk. I praksis afgør denne struktur dog helt direkte, om nye clients, services, tests og udvidelser kan kobles roligt på eller løber dyrt fra hinanden.
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på voksede monolitter, modstridende udvidelser og dyre koblinger i hverdagen.
Hvorfor er Layer-3 så vigtig ved virksomhedsapplikationer?
Fordi det først er den rene adskillelse af UI, business-logik og dataadgang, der sikrer, at udvidelser, tests, services og nye platforme ikke fejler direkte på monolitten.
Giver Layer-3 kun mening for store projekter?
Nej. Især mellemstore systemer får stor fordel af det, fordi senere krav dermed kan kobles på langt mere kontrolleret.
Hvad er den hyppigste fejl ved Layer-3?
At man kun tegner lag formelt, men fortsat skjuler de egentlige regler i UI-koden eller direkte i særlige SQL-stier. Så findes opbygningen kun på slides, ikke i systemet.
Læs videre om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den dybdegående fag-side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Delphi-team
Delphi-udviklere fra Freiburg
Ved denne forespørgsel handler det sjældent kun om en tilgængelig person. Oftest ligger der spørgsmålet bag, om en partner reelt kan overtage legacy, forretningslogik, dataadgang og den tekniske retning på en måde, der kan bære.
Når man søger Delphi-udviklere, handler det sjældent kun om ledig kapacitet. Oftest handler det om en robust overtagelse af eksisterende system, arkitektur, dataadgang og reelt fagligt ansvar.
Hvornår giver en ekstern Delphi-udvikler mening?
Frem for alt når der mangler viden om den eksisterende løsning, modernisering er gået i stå, eller en applikation skal videreudvikles fagligt, uden at miste sin substans.
Kan I også gå ind i voksede Delphi-applikationer?
Ja. Netop det er et fokusområde: Vi analyserer legacy-kode, database, deployment, specialtilfælde og faglige forløb og bygger kontrolleret videre på det.
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 reel drift.
Læs videre om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den dybdegående fag-side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Vedligeholdelse
Delphi-vedligeholdelse & drift
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 voksende system igen kan videreudvikles roligt.
Vedligeholdelse er i voksede Delphi-systemer mere end bugfixing. Den vedrører releasesikkerhed, datakonsistens, teknisk gæld og spørgsmålet om, hvordan nye krav roligt passer ind i den eksisterende løsning.
Hvad hører til god Delphi-vedligeholdelse?
Fejlanalyse, videreudvikling, databasepleje, release-ledsagelse, teknisk dokumentation og en arkitektur, der ikke gør nye krav dyrere hver gang.
Kan driftstøtte også 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ængighed af enkeltpersoners viden?
Ved at dokumentere datapaths, komponenter, build-trin og kritisk forretningslogik struktureret og ved at gøre implicit viden til gennemskuelig systemlogik igen.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Modernisering
Delphi-modernisering
Disse svar hjælper især dér, hvor en legacy-applikation fagligt stadig er stærk, men teknisk har samlet for mange flaskehalse til at kunne 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 den daglige drift.
Skal en gammel Delphi-applikation udskiftes helt?
Nej. Ofte giver en kontrolleret ombygning mere mening: forny dataadgang, afkoble logik, supplere med services og modernisere brugerflader målrettet.
Hvordan undgår man driftsbrud ved modernisering?
Med klare mellemtrin, rene grænseflader og en migrationssti, hvor gamle og nye dele kontrolleret kan eksistere side om side.
Kan eksisterende forretningslogik senere også overgå til services eller portaler?
Ja. Netop derfor frigør vi business-logik fra UI-nær legacy-kode og flytter den ind i en struktur, som clients, services og API’er kan bruge sammen.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Dataadgang
BDE-udfasning
BDE er sjældent kun en gammel driver. Den hænger typisk sammen med historisk SQL-logik, databaseantagelser og deployment-stier. Netop derfor besvarer vi emnet her bevidst lidt bredere.
BDE er sjældent kun en enkelt teknisk byggesten. Den hænger sammen med SQL, deployment, drivere, tegnsæt og historiske sideeffekter. Derfor behandler vi udskiftningen som et moderniseringstrin og ikke som et komponentbytte.
Er et skifte til FireDAC eller native drivere muligt uden en komplet ombygning?
Ja, ofte i trin. Det vigtige er at gennemgå SQL, datatyper, transaktioner og særtilfælde rent, frem for blot at erstatte komponenter 1:1.
Hvorfor berører BDE-udskiftningen næsten altid også databasestrukturen?
Fordi man i den forbindelse ofte får øje på gamle tabeller, indekser, tegnsæt og historisk voksede SQL-stier, som bør ryddes med af hensyn til stabilitet og performance.
Hvad vinder 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 vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den, der bruger PostgreSQL og BDE-Ablösung mit nativer Anbindung, ønsker som regel mere end blot en ny komponent. Bagved ligger ofte spørgsmålet om, hvordan dataadgang, SQL, deployment og eksisterende logik bringes tilbage på en bæredygtig linje.
Med PostgreSQL og BDE-Ablösung mit nativer Anbindung handler det ikke kun om en ny forbindelseskomponent. Ofte ligger der et større skridt mod mere robust SQL, bedre deployment og kontrollerbar datahåndtering.
Hvornår er PostgreSQL et godt valg for Delphi?
Altid når stabilitet, flerbrugerdrift, klare SQL-stier, åben infrastruktur og ren udvidelsesmulighed 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 den konkrete eksisterende løsning.
Kan BDE-, Paradox- eller gamle SQL-systemer trinvis gå over til PostgreSQL?
Ja. I mange tilfælde er en kontrolleret trinvist overgang mere økonomisk end et hårdt cut, så længe datamodel og faglogik tænkes rent med.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Delphi REST
Delphi REST-API & REST-Server
Denne FAQ besvarer det typiske principspørgsmål, om REST med Delphi blot er et teknisk supplement eller en seriøs serverstrategi. Afgørende er altid, hvor rent klient, regler, data og drift holdes samlet.
REST med Delphi bliver stærkt, når API’er ikke står løsrevet ved siden af det eksisterende system, men rent bærer rettigheder, forretningslogik, datamodel og drift med.
Kan man bygge produktive REST-API’er med Delphi?
Ja. Særligt når den samme domænelogik allerede lever i den eksisterende Delphi-løsning, er en rent afgrænset REST-server ofte mere økonomisk end en fuldstændig ny parallel verden.
Hvornår kan en REST-server betale sig i forhold til direkte databaseadgang?
Så snart flere klienter, portaler, tjenester eller integrationer kontrolleret skal bruge de samme regler, og direkte SQL-adgang bliver for risikabelt fagligt set.
Hvordan holder I Delphi-klient og REST konsistente?
Med en arkitektur, hvor forretningsregler ikke forbliver skjult i formularer, men bliver fælles anvendelige for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den mere dybdegående faglige side, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Tjenester
Windows- & Linux-services
Ved services handler det sjældent kun om en kørende proces. Vigtigere er logging, observability, genstart, datakonsistens og det faglige spørgsmål om, hvilke dele der hører til i baggrunden, og hvilke der ikke gør.
Baggrundstjenester er ofte den usynlige kerne i et system. De skal køre roligt, håndtere tilstandsskift rent og passe robust ind i driften med logging, restart og monitoring.
Hvornår har en forretningsapplikation yderligere brug for Windows- eller Linux-services?
Altid når import, eksport, tidsstyring, synkronisering, licenslogik eller integrationer ikke skal være bundet til et logget ind desktop-miljø.
Kan services og REST komme fra den 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 services?
Klar fejlhåndtering, observerbare tilstande, restart-sikkerhed, logging, deployment og en fagligt konsistent behandling i stedet for stille baggrundsmagi.
Læs emnet i detaljer
Hvis du vil gå fra denne FAQ til den mere dybdegående faglige side, finder du dér 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 reelt bliver økonomiske.
Multiplatform fungerer kun rent, når kodebase, datamodel, platformsforskelle og deployment planlægges bevidst. Det er præcis dér, den egentlige projektværdi opstår.
Kan den samme applikation virkelig køre på Windows, macOS og Linux?
Ja, hvis brugerflade, forretningslogik, platformsærligheder og release-processer ikke blandes sammen, men struktureres rent.
Hvad er den hyppigste fejl i multiplatform-projekter?
At tænke for sent over filsystem, udskrift, signering, målplatforme, packaging og UI-forskelle. Så bliver 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 De vil skifte fra denne FAQ til den mere dybdegående fagside, finder De dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Serverarkitektur
REST-server & services
Hvis API’er og tjenester kun lyder teknisk moderne, men ikke er fagligt rent afgrænset, bliver de hurtigt et problem. Denne FAQ indplacerer netop disse beslutninger.
Mange systemer fejler ikke på API-idéen, men på at serverlogik senere improviseres og hægtes på en eksisterende desktop-base. Vi planlægger disse dele bevidst samlet.
Hvornår har en forretningsapplikation derudover brug for en REST-server?
Så snart flere clients, portaler, mobile adgangsveje, eksterne integrationer eller afkoblede processer kontrolleret skal bruge den samme forretningslogik.
Understøtter De også Windows- og Linux-services?
Ja. Baggrundsprocesser, tidsstyring, synkronisering, eksport, licenstjenester og tekniske følgeprocesser hører til vores typiske opgaver.
Hvordan bevares den faglige konsistens mellem client, REST og service?
Gennem en arkitektur, hvor business-regler ikke er skjult i enkelte brugerflader, men forbliver fælles anvendelige og sporbare.
Læs emnet i detaljer
Hvis De vil skifte fra denne FAQ til den mere dybdegående fagside, finder De dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Platform
Windows 11 ARM64
ARM64 rammer mange applikationer tidligere end forventet. Denne FAQ besvarer de typiske spørgsmål om afhængigheder, test, installere og den økonomiske indplacering af ny målhardware.
ARM64 er ikke længere et eksotisk sidespor, men en reel målplatform. Den, der tænker det ind 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 satser på det, og teknisk efterarbejde senere bliver markant dyrere end en tidlig arkitekturbeslutning.
Hvad er særligt kritisk ved Delphi og native afhængigheder på ARM64?
Især eksterne biblioteker, databasedrivere, installere, setup-processer og tests på reel målhardware skal kontrolleres tidligt.
Skal der udvikles et helt særskilt produkt til ARM64?
Ikke nødvendigvis. Ofte er det nok at forberede build- og deployment-stierne rent og afkoble kritiske native afhængigheder i god tid.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fag-side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Skal en FAQ blive til en konkret projektsamtale?
Så er det næste fornuftige skridt ikke endnu en samling af buzzwords, men en struktureret indplacering af din eksisterende løsning: Hvilken faglogik findes der, hvor bremser den nuværende arkitektur, hvilke grænseflader er kritiske, og hvilken udbygningssti er teknisk set reelt bæredygtig?