Oversigt
FAQ Virksomhedssoftware im überblick
Egnet service- og teknikforløb
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 organiserer vi dem yderligere som en landingsside, 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 springe direkte til en emneblok eller fra neden skifte til den uddybende underside. Dermed fungerer siden både som en hurtig indgang og som en struktureret FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbejde
Spørgsmål om en fornuftig opstart, om kortlægning af eksisterende forhold og om tidlige arkitekturvalg.
Direkte til svarene
Ydelser
Oversigt over ydelser
Spørgsmål om overtagelse af eksisterende løsninger, modernisering, services, dataadgang og langsigtet support.
Direkte til svarene
Teknologier
Teknologi og arkitektur i overblik
Spørgsmål om Delphi, C#, Layer-3, platformvalg og den tekniske linje på tværs af flere udvidelsesfaser.
Direkte til svarene
Projekter
Projektbilleder og referencemønstre
Spørgsmål om projektstørrelse, driftsansvar, hosting, produktlogik og langtidsholdbare systemer.
Direkte til svarene
Virksomhedssoftware
Skræddersyet virksomhedssoftware & Layer-3
Spørgsmål om økonomi, proceslogik, roller, data og langsigtet udvidbarhed.
Direkte til svarene
Ydelse
Tværplatform med Delphi
Spørgsmål om Windows, macOS, Linux samt senere iOS- og Android-veje baseret på fælles domænelogik.
Direkte til svarene
Ydelse
Services, REST-servere & portaler
Spørgsmål om portaler, API’er, Windows- og Linux-services som del af den samme fagarkitektur.
Direkte til svarene
Integration
Grænseflader, datastrømme & platformsmål
Spørgsmål om Fibu, API’er, databaseombygning, mapping, overvågning og nye målplatforme.
Direkte til svarene
Delphi
Delphi til virksomhedsapplikationer
Hvorfor Delphi fortsat kan være stærk ved voksende forretningslogik, rapporter og produktive desktop-processer.
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 økonomisk direkte relevant.
Direkte til svarene
Delphi-team
Delphi-udviklere fra Freiburg
Spørgsmål om ekstern støtte, overtagelse af eksisterende systemer og teknisk ansvar i etablerede Delphi-systemer.
Direkte til svarene
Betjening
Delphi-Wartung & Betreuung
Spørgsmål om stabilisering, videreudvikling, release-sikkerhed og reduktion af enkeltmandsviden.
Direkte til svarene
Modernisering
Delphi-Modernisierung
Spørgsmål om ombygningsvej, risiko, bevarelse af forretningslogik og trinvis fornyelse under løbende drift.
Direkte til svarene
Dataadgang
BDE-Ablösung
Spørgsmål om FireDAC, nativen Treibern, SQL-Besonderheiten, udrulning og database-omlægning.
Direkte til svarene
PostgreSQL
Delphi, PostgreSQL & FireDAC
Spørgsmål om PostgreSQL-migration, nativen Treibern, SQL-Verhalten og en rolig ombygning af dataadgangen.
Direkte til svarene
Delphi REST
Delphi REST-API & REST-Server
Spørgsmål om REST med Delphi, API-udformning, fælles forretningslogik og ren serverarkitektur.
Direkte til svarene
Tjenester
Windows- & Linux-Services
Spørgsmål om baggrundstjenester, tidsstyring, overvågning, genstartadfærd og klar driftsafgrænsning.
Direkte til svarene
Teknologi
Delphi Multiplattform
Spørgsmål om en fælles kodebase for Windows, macOS og Linux med kontrollerede platformgrænser.
Direkte til svarene
Serverarkitektur
REST-Server & Services
Spørgsmål om API’er, Windows- und Linux-Diensten, serverlogik, overvågning und 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 første 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 et holdbart afsæt for 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 man afklare tidligt, og hvornår er modernisering mere fornuftigt end hektisk nyudvikling?
Hvornår er Delphi-modernisering værd at foretrække frem for en komplet nyudvikling?
Hvis forretningslogik, processer og datamodel er værdifulde, er en kontrolleret ombygning ofte mere økonomisk end at starte forfra med tab af funktionalitet og høj implementeringsrisiko.
Kan den samme forretningslogik køre for Windows, macOS og Linux?
Ja. Især i Delphi-projekter planlægger vi fælles forretningslogik og adskiller præsentationslag, Services og dataadgang, så flere platforme kan forsynes 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 monteret i efteråret.
Hvordan starter et typisk projekt?
Som regel med en struktureret statusopgørelse: mål, eksisterende systemer, database, platforme, grænseflader og driftsrisici. Ud fra dette 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 den større sammenhæng med arkitektur, eksempler, beslutningsårsager og tilstødende emner.
Ydelser
Oversigt over ydelser
På ydelsessiden opstår som regel de bredeste opfølgende spørgsmål: Hvad overtager vi konkret, hvor langt rækker vores tekniske ansvar, og hvordan griber modernisering, integrationer, drift og videreudvikling ind i hinanden?
Især ved etablerede applikationer dukker ofte de samme faglige og tekniske spørgsmål op. Disse punkter afklarer vi tidligt, før et initiativ udvikler sig til et diffust storprojekt.
Overtager I også eksisterende Delphi-systemer?
Ja. Vi træder regelmæssigt ind i etablerede Delphi-applikationer, analyserer den eksisterende tilstand, dataadgang, arkitektur og specialtilfælde og bygger derefter videre på en kontrolleret måde.
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 ender med at blive udført i flere separate specialløsninger.
Er en BDE-afløsning også mulig uden komplet udskiftning?
I mange tilfælde ja. Vi løsgør dataadgang, SQL og Deployment gradvist fra den gamle struktur og bygger en native, vedligeholdelsesvenlig integration.
Støtter I også drift og videreudvikling?
Ja. Release-processer, Hosting, fejlanalyse, databasevedligeholdelse og senere udvidelser er en del af vores arbejdsområde.
Thema im Detail weiterlesen
Hvis du fra denne FAQ vil gå videre til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Teknologier
Teknologi og arkitektur i overblik
Denne FAQ samler de typiske orienteringsspørgsmål om teknologivalg: Hvornår er Delphi en stærk løsning, hvornår er C# den bedre komponent, og hvordan fører en velstruktureret arkitektur flere platforme, services og klienter sammen på kontrolleret vis?
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æssig i forhold til en komplet ny platform?
Altid når opbygget faglogik, performante desktopprocesser og multiplatformmål økonomisk set skal videreføres i stedet for at udskifte substansen uden omtanke.
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 platformskift håndterbare.
Inddrager I nye platforme som Windows 11 ARM64 tidligt i planen?
Ja. Ny målhardware og deploymentsveje bliver vurderet tidligt, så det senere ikke udvikler sig til kostbare særprojekter.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå videre til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Projekter
Projektbilleder og referencemønstre
Den, der kigger på projektsiden, vil som regel forstå, hvilken type projekter vi reelt understøtter: enkeltstående værktøjer eller længerelevende systemer med drift, rettighedskoncept, versionering, integrationer og reel videreudvikling.
Mange projekter lyder i starten forskellige, men har alligevel fælles mønstre: opbygget faglogik, integrationer, rettigheder, versionering, driftsspørgsmål og langsigtet udvidbarhed.
Arbejder I mest med enkeltstående værktøjer eller med langtidsholdbare 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 længere opbyggede systemer 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 kun udvikles, men også kan drives stabilt.
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, beslutningsbegrundelser og relaterede 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 virksomheden ønsker at vide, om et skræddersyet system realistisk kan bygges økonomisk gennemførligt, vedligeholdelsesvenligt og udbyggeligt.
Især ved skræddersyet virksomhedssoftware handler det ikke kun om enkelte skærmbilleder, men om roller, data, kontrolforløb og en arkitektur, der også senere forbliver fleksibel.
Er skræddersyet virksomhedssoftware kun relevant for meget store virksomheder?
Nej. Den er relevant, 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 bestående processer?
Ja. Især dér bliver vores arbejde stærkt, fordi vi gør fagprocesser, eksisterende data og gammel logik læsbar og udvikler deraf en holdbar målarkitektur.
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, beslutningsbegrundelser og relaterede emner.
Se skræddersyet virksomhedssoftware & Layer-3-applikationer i detaljer
Ydelser
Multiplatform med Delphi
Virksomheder spørger her typisk ikke kun efter en teknisk mulighed, men efter en robust strategi: Hvilke dele forbliver fælles, hvad skal håndteres platformspecifikt, og hvordan undgås et dyrt parallelt byggeri?
Multiplatform bliver først værdifuld, når den samme faglogik forbliver kontrolleret samlet på tværs af flere målplatforme, og platformspecifikke forskelle synliggøres tidligt.
Kan der med Delphi ud over Windows også macOS, Linux, iOS og Android medtænkes?
Ja. Afhængigt af projektets mål planlægger vi desktopmål, mobile brugerflader og servernære komponenter ud fra en fælles faglig linje i stedet for at opbygge hver platform fagligt for sig.
Hvordan undgår I, at multiplatformprojekter fagligt divergerer?
Gennem en fælles kode- og arkitekturstrategi: fagregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst indkapsles.
Er mobile udvidelser også mulige på et senere tidspunkt?
Ja. Hvis arkitektur, services og grænseflader er grundigt forberedt, kan iOS- eller Android-mål senere tilknyttes betydeligt mere kontrolleret.
Læs emnet i detaljer videre
Hvis du fra denne FAQ vil skifte til den mere faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Ydelser
Services, REST-Server & Portale
Især her skal rettigheder, dataflows, Logging og faglige regler holdes sammen. Derfor behandler vi emnet ikke som en web-påbygning, men som en ordnet udbygning af samme applikationslinje.
Portaler, REST-APIs og tjenester sælger sig kun godt, hvis de fagligt ikke står ved siden af kernesystemet, men rent viderefører den samme data- og rollelogik.
Udvikler I både REST-server samt Windows- og Linux-Services?
Ja. Baggrundstjenester, API’er, importer, eksporter, portaler og teknisk driftslogik er blandt vores tilbagevendende opgaver.
Hvornår har en virksomhedsapplikation yderligere brug for en portal?
Altid når kunder, partnere eller interne roller skal have kontrolleret adgang til de samme processer, uden at man duplikerer faglige regler i adskilte brugerflader.
Hvordan holdes rettigheder, Logging og processer mellem Client og Server konsistente?
Ved at vi ikke skjuler fagregler i individuelle Endpoints eller brugergrænseflader, men skaber en klar faglig midte, som Client, Portal og Service kan benytte sammen.
Læs emnet i detaljer videre
Hvis du fra denne FAQ vil skifte til den mere faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsbegrundelser og tilstødende emner.
Integration
Grænseflader, dataflows & platformmål
Disse spørgsmål opstår som regel, når datakvalitet, sporbarhed og fremtidige platformskift bliver vigtigere end ren dataoverførsel fra A til B.
Grænseflader virker ofte som sidespørgsmål. I virkeligheden afgør de datakvalitet, sporbarhed, platformskifte og stabil drift.
Kan eksisterende grænseflader og dataflows fornyes uden Big Bang?
Ja. I mange projekter omorganiserer vi Mapping, Datenbankpfade, Jobs og Integrationen gradvist, så reelle processer kan fortsætte.
Håndterer I også integrationer til finansbogføring og tredjepartssystemer?
Ja. Især Fibu, API’er, CRM, lager, Lizenzlogik eller branchespecifikke tredjepartssystemer skal tilsluttes klart dokumenteret, observerbart og fagligt kontrollerbart.
Indtænker I platformsmål som Windows 11 ARM64 i sådanne integrationsprojekter fra starten?
Ja. Nye målplatforme, native afhængigheder og fremtidige Deployment-Wege hører tidligt til i samme planlægning som grænseflader og dataflowlogik.
Læs emnet i detaljer videre
Hvis du fra denne FAQ ønsker at skifte til den dybdegående fagartikel, finder du der den bredere kontekst med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Delphi
Delphi til virksomhedsapplikationer
Her handler det om det principielle spørgsmål om, hvornår Delphi også i dag er et bevidst arkitekturvalg, og hvornår andre komponenter fornuftigt bør supplere eller overtage.
I forhold til Delphi drejer det sig i virksomheder sjældent om nostalgi, men om, hvordan eksisterende faglogik, desktop-processer og flere målplatforme økonomisk og på en kontrolleret måde kan videreføres.
Hvorfor vælger man i dag stadig bevidst Delphi?
Fordi Delphi i mange virksomhedsapplikationer tilbyder en stærk kombination af etableret forretningslogik, højtydende desktop-processer, tæt databasetilknytning og kontrolleret videreudvikling.
Er Delphi kun interessant til modernisering af eksisterende systemer?
Nej. Delphi giver også mening for nye virksomhedsapplikationer, når produktive desktop-processer, 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. Så kombinerer vi bevidst Delphi med C#, REST-servere eller webkomponenter i stedet for at presse alt ind i ét værktøj.
Læs emnet i dybden
Hvis du fra denne FAQ ønsker at skifte til den dybdegående fagartikel, finder du der den bredere kontekst med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
C#
C# til tjenester & portaler
Denne FAQ henvender sig til virksomheder, der ønsker at forstå C# ikke som et mål i sig selv, men som en stærk komponent 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 klart afgrænset driftsansvar 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 man C# også sammen med eksisterende Delphi-systemer?
Ja. Netop denne kombination er ofte fornuftig: Delphi placerer produktiv faglogik i klienten, mens C# supplerer services, portaler og API-lag.
Hvad er typiske risici ved C#-projekter?
Ofte bygges der teknisk moderne for hurtigt, uden at skære roller, faglogik, logging, deployment og reelle driftsaspekter rent nok tidligt. Netop dér griber vi ind.
Læs emnet i dybden
Hvis du fra denne FAQ ønsker at skifte til den dybdegående fagartikel, finder du der den bredere kontekst med arkitektur, eksempler, beslutningsgrundlag og tilgrænsende emner.
Arkitektur
Layer-3-Arkitektur
Layer-3 bliver ofte forklaret teoretisk. I praksis afgør denne struktur dog meget direkte, om nye klienter, Services, tests og udvidelser kan tilsluttes uden problemer eller ender med dyre afkoblinger.
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på opståede monolitter, modstridende udvidelser og dyre koblinger i praksis.
Hvorfor er Layer-3 så vigtig for virksomhedsapplikationer?
Fordi det først er den klare adskillelse af UI, forretningslogik og dataadgang, der sikrer, at udvidelser, tests, Services og nye platforme ikke straks fejler på monolitten.
Er Layer-3 kun hensigtsmæssig for store projekter?
Nej. Særligt mellemstore systemer har stor fordel af det, fordi senere krav kan tilknyttes væsentligt mere kontrolleret.
Hvad er den hyppigste fejl ved Layer-3?
At man kun tegner lagene formelt, mens de egentlige regler fortsat ligger skjult i UI-koden eller direkte i særlige SQL-stier. Så findes opbygningen kun i præsentationerne, ikke i systemet.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Delphi-Team
Delphi-udviklere fra Freiburg
Ved denne forespørgsel drejer det sig sjældent kun om en tilgængelig person. Ofte er spørgsmålet, om en partner kan overtage eksisterende kodebestand, forretningslogik, dataadgang og den tekniske retning pålideligt.
Ved søgning efter Delphi-udviklere handler det sjældent kun om ledig kapacitet. Ofte drejer det sig om en pålidelig overtagelse af kodebestand, arkitektur, dataadgang og reel faglig ansvarlighed.
Hvornår giver det mening med en ekstern Delphi-udvikler?
Især når viden om det eksisterende mangler, moderniseringen er gået i stå, eller en applikation skal fagligt videreudvikles uden at miste sin substans.
Kan I også gå ind i eksisterende Delphi-applikationer?
Ja. Netop det er et fokusområde: Vi analyserer gammel kode, database, deployment, specialtilfæ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 fagartikel, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende 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 på voksede Delphi-systemer mere end fejlretning. 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, databasevedligehold, release-opfølgning, teknisk dokumentation og en arkitektur, der ikke altid gør nye krav dyrere.
Kan 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 dokumentere dataveje, komponenter, build-trin og kritisk faglogik struktureret og derved gøre implicit viden til efterprøvbar systemlogik.
Læs emnet i detaljer
Hvis I fra denne FAQ vil gå videre til den mere dybdegående fagside, finder I der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende 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 at bære nye krav ordentligt.
Det kritiske punkt ved modernisering er sjældent kun overfladen. Som regel handler det om faglogik, data, afhængigheder og en migrationsstrategi, der fungerer i daglig drift.
Skal en gammel Delphi-applikation fuldstændigt erstattes?
Nej. Ofte er en kontrolleret ombygning mere fornuftig: forny dataadgang, afkoble logik, tilføje services og målrette modernisering af brugergrænseflader.
Hvordan undgår man driftsstop ved modernisering?
Gennem klare mellemtrin, rene grænseflader og en migrationssti, hvor gamle og nye dele kan eksistere kontrolleret side om side.
Kan eksisterende faglogik senere også overføres til services eller portaler?
Ja. Netop derfor frigør vi forretningslogik fra UI-nær gammel kode og bringer den ind i en struktur, som clients, services og API’er fælles kan bruge.
Læs emnet i detaljer
Hvis I fra denne FAQ vil gå videre til den mere dybdegående fagside, finder I der det større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Dataadgang
BDE-Afløsning
BDE er sjældent kun en gammel drivkraft. Den hænger som regel sammen med historisk SQL-logik, databaseantagelser og udrulningsveje. Netop derfor behandler vi emnet her bevidst lidt bredere.
BDE er sjældent blot en enkelt teknisk komponent. Den hænger sammen med SQL, deployment, drivere, tegnsæt og historiske sideeffekter. Derfor betragter vi udskiftningen som et moderniseringsskridt og ikke som et rent komponentudskifte.
Er et skifte til FireDAC eller native drivere muligt uden komplet ombygning?
Ja, ofte i etaper. Vigtigt er at gennemgå SQL, datatyper, transaktioner og særlige tilfælde grundigt i stedet for blot at erstatte komponenter 1:1.
Hvorfor berører BDE-udskiftningen næsten altid også databasestrukturen?
Fordi der ofte dukker gamle tabeller, indeks, tegnsæt og historisk opståede SQL-stier op, som bør indgå i oprydningen for at sikre stabilitet og ydeevne.
Hvad får man konkret ved native databaseforbindelse?
Enklere deployment, bedre vedligeholdelse, kontrollerbare forbindelser og et markant bedre grundlag for services, API’er og kommende udvidelser.
Læs mere om emnet i detaljer
Hvis du vil gå fra denne FAQ til den dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningskriterier og tilstødende emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den, der bruger PostgreSQL og BDE-Ablosung 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 forretningslogik igen kan bringes i en holdbar linje.
Med PostgreSQL og FireDAC handler det ikke blot om en ny forbindelseskomponent. Ofte er der tale om et større skridt mod mere robust SQL, bedre deployment og kontrollerbar datastyring.
Hvornår er PostgreSQL et godt valg for Delphi?
Når stabilitet, multi-bruger-drift, 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 løsning, men ikke som blind udskiftning. Afgørende er SQL-adfærd, datatyper, transaktioner, fejlsstier og det konkrete bestandsmiljø.
Kan BDE-, Paradox- eller gamle SQL-systemer gradvist overgå til PostgreSQL?
Ja. I mange tilfælde er en kontrolleret etapevis plan mere økonomisk end et hårdt brud, så længe datamodel og faglogik medtænkes korrekt.
Læs mere om emnet i detaljer
Hvis du vil gå fra denne FAQ til den dybdegående fagside, finder du 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 REST med Delphi blot er et teknisk tillæg eller en seriøs serverstrategi. Afgørende er altid, hvor godt klient, regler, data og drift holdes sammen.
REST med Delphi bliver stærkt, når API’er ikke står isoleret ved siden af det bestående system, men konsekvent understøtter rettigheder, forretningslogik, datamodel og drift.
Kan man med Delphi bygge produktive REST-API’er?
Ja. Især når den samme faglogik allerede er en del af det eksisterende Delphi-miljø, er en velafgrænset REST-server ofte mere økonomisk end en helt ny parallel verden.
Hvornår er en REST-server fordelagtig i forhold til direkte databaseadgang?
Så snart flere klienter, portaler, tjenester eller integrationer under kontrollerede forhold skal bruge de samme regler, og direkte SQL-adgang bliver fagligt for risikabel.
Hvordan holder I Delphi-klient og REST konsistente?
Gennem en arkitektur, hvor forretningsregler ikke forbliver skjult i formularer, men bliver tilgængelige fælles for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den mere dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Tjenester
Windows- & Linux-tjenester
Når det gælder tjenester, handler det sjældent kun om en kørende proces. Vigtigere er logning, observerbarhed, genstartssikkerhed, datakonsistens og det faglige spørgsmål, hvilke dele hører hjemme i baggrunden og hvilke ikke.
Baggrundstjenester er ofte systemets usynlige kerne. De skal køre stabilt, håndtere tilstandsændringer ordentligt og integreres robust i driften med logning, genstart og overvågning.
Hvornår har en virksomhedsapplikation brug for yderligere Windows- eller Linux-tjenester?
Altid når importer, eksporter, tidsstyring, synkronisation, licenslogik eller integrationer ikke skal være bundet til en logget‑in desktop.
Kan tjenester og REST komme fra samme arkitektur?
Ja. Det er ofte fornuftigt, fordi forretningslogik, datamodel og logning dermed ikke splittes op i flere tekniske øer.
Hvad er særligt vigtigt for produktive tjenester?
Klar fejlbehandling, observerbare tilstande, genstartssikkerhed, logning, udrulning og en fagligt konsekvent behandling i stedet for stille baggrundsmagi.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den mere dybdegående faglige side, 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 rentable.
Multiplatform fungerer kun ordentligt, når kodebase, datamodel, platformforskelle og deployment planlægges med omtanke. Netop dér opstår den reelle projektværdi.
Kan den samme applikation virkelig køre på Windows, macOS og Linux?
Ja — hvis brugerflade, forretningslogik, platformsspecifikke forhold og release-processer ikke blandes, men holdes klart adskilt.
Hvad er den hyppigste fejl i multiplatformprojekter?
At tænke for sent over filsystem, udskrivning, signering, målplatforme, pakning og UI-forskelle. Så bliver multiplatform hurtigt dyrt og inkonsekvent.
Kan services og API’er bruge den samme forretningslogik?
Ja. En god arkitektur sikrer, at ikke hver platform udvikler sin egen faglige særvej.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Serverarkitektur
REST-Server & Services
Hvis APIs og tjenester kun lyder teknisk moderne, men ikke er fagligt korrekt opdelt, 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 og føjes til en eksisterende desktop-installation. Vi planlægger disse dele bevidst sammen.
Hvornår har en virksomhedsapplikation brug for en REST-server?
Så snart flere klienter, portaler, mobiladgange, eksterne integrationer eller løst koblede processer skal kontrolleret anvende 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 den faglige konsistens mellem klient, REST og service?
Gennem en arkitektur, hvor forretningsregler ikke er skjult i enkelte brugerflader, men forbliver fælles anvendelige og efterprøvelige.
Læs emnet i detaljer
Hvis du fra denne FAQ vil skifte til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende 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 i udrulning og i forbindelse med native afhængigheder.
Hvorfor bør Windows 11 ARM64 allerede tages i betragtning?
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 reelle målhardware skal verificeres tidligt.
Skal der for ARM64 udvikles et helt selvstændigt produkt?
Ikke nødvendigvis. Ofte er det tilstrækkeligt at forberede build- og deployment-pipelines korrekt og afkoble kritiske native afhængigheder rettidigt.
Læs emnet i detaljer
Hvis du fra denne FAQ vil gå til den mere dybdegående fagside, finder du der sammenhængen med arkitektur, eksempler, beslutningskriterier og tilstødende emner.
Skal en FAQ udvikle sig til en konkret projektdrøftelse?
Så er det næste fornuftige skridt ikke endnu en samling af nøgleord, men en struktureret indplacering af jeres eksisterende system: Hvilken forretningslogik er til stede, hvor bremser den nuværende arkitektur, hvilke grænseflader er kritiske, og hvilken udbygningsvej er teknisk holdbar?
Konkrete optimeringer
1) Reducer duplikater: Lad landingssiden kun indeholde 1–2-sætningers resumé for hvert spørgsmål og link til de fuldstændige svar på detaljesiderne. 2) Entydige metadata: Angiv for landings- og detaljesider hver deres egen, prægnante H1 og meta-beskrivelser, så Google kan skelne indhold korrekt. 3) Sitemap & linkning: Indsæt landingssiden i XML-Sitemap og sørg for mindst ét internt link fra hovednavigationen eller sidefoden for at fjerne ‚nicht verlinkt in Sitemap‘-advarslen. 4) Canonical-strategi: Ved sammenførte indhold enten angiv kanoniske URLs eller sammenfør via 301 i stedet for at lade identiske tekster ligge på flere URLs. 5) Kontrol: Efter implementering tjek ændringer i Search Console (indekseringsstatus, crawling-fejl).
Kortfristede forbedringer (SEO & Struktur)
Kort gennemførlige tiltag: Formulér på denne hub-side for hver temablok et unikt kort resumé (1–2 sætninger) og link til de udførlige svar for at undgå duplikeret indhold; sørg for, at siden er indskrevet i XML-Sitemap og tilgængelig internt fra relevante oversigtssider; angiv en prægnant meta-beskrivelse og tilføj om nødvendigt FAQ-Structured-Data (schema.org), så søgemaskiner og brugere bedre kan klassificere siden.
Næste skridt
Hvis I har et konkret moderniserings-, API- eller platformsspørgsmål, bør vi tidligt præcist afklare den tekniske udformning.
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, datatilgang, portaler og udrulning bliver ikke udskudt til senere faser.
- I ser tidligt, hvilken vej der er økonomisk og operationelt holdbar.