Frågor och svar
Centrala FAQ – översikt
Lämpliga prestanda- och teknikvägar
Viktiga fördjupningar i detta ämne
FAQ-landningssida
Centrala frågor och svar om projektstart, tjänster, företagsprogramvara, Delphi, arkitektur, portaler, Services och modernisering.
Denna sida samlar de vanligaste frågorna från vår startsida, översiktssidorna och ämnesspecifika undersidor på ett och samma ställe. De kompakta FAQ:arna behålls medvetet på respektive detaljsida. Här ordnar vi dem dessutom som en landningssida så att intressenter snabbt kan se vilka ämnen vi verkligen behärskar inom projektstart, tjänster, Delphi, C#, Layer-3, portaler, modernisering, dataåtkomst och plattformstrategi.
Du kan antingen hoppa direkt till en ämnesavdelning eller från nedan byta till respektive fördjupande undersida. På så sätt fungerar sidan både som snabb ingång och som ett strukturerat FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbete
Frågor om lämplig start, inventering och tidiga arkitekturval.
Direkt till svaren
Tjänster
Tjänster i översikt
Frågor om övertagande av befintliga system, modernisering, Services, dataåtkomst och långsiktig förvaltning.
Direkt till svaren
Teknologier
Teknologi och arkitektur – översikt
Frågor om Delphi, C#, Layer-3, plattformsval och den tekniska linjen över flera utbyggnadsfaser.
Direkt till svaren
Projekt
Projektbilder och referensmönster
Frågor om projektstorlek, driftsansvar, Hosting, produktlogik och system med lång livslängd.
Direkt till svaren
Företagsprogramvara
Individuell företagsprogramvara & Layer-3
Frågor om lönsamhet, processlogik, roller, data och långsiktig utbyggbarhet.
Direkt till svaren
Prestanda
Multiplattform med Delphi
Frågor om Windows, macOS, Linux samt senare iOS- och Android-spår från gemensam domänlogik.
Direkt till svaren
Prestanda
Tjänster, REST-servrar & portaler
Frågor om portaler, API:er, Windows- och Linux-tjänster som del av samma domänarkitektur.
Direkt till svaren
Integration
Gränssnitt, dataflöden & plattformsmål
Frågor om Fibu, API:er, databasombyggnad, mappning, övervakning och nya målplattformar.
Direkt till svaren
Delphi
Delphi för företagsapplikationer
Varför Delphi kan fortsätta vara starkt vid växande affärslogik, rapporter och produktiva desktopprocesser.
Direkt till svaren
C#
C# för tjänster & portaler
Frågor om REST, integrationer, portaler, backendtjänster och stabil drift.
Direkt till svaren
Arkitektur
Layer-3-arkitektur
Frågor om separationen mellan UI, affärslogik och dataåtkomst och varför det är ekonomiskt direkt relevant.
Direkt till svaren
Delphi-Team
Delphi-utvecklare från Freiburg
Frågor om extern support, övertagande av befintligt system och tekniskt ansvar i etablerade Delphi-system.
Direkt till svaren
Support
Delphi-Underhåll & support
Frågor om stabilisering, vidareutveckling, releasesäkerhet och minskning av beroendet av enskild kunskap.
Direkt till svaren
Modernisering
Delphi-Modernisering
Frågor om ombyggnadsplan, risk, bevarande av domänlogik och gradvis förnyelse i drift.
Direkt till svaren
Dataåtkomst
BDE-ersättning
Frågor om FireDAC, native drivrutiner, SQL-särdrag, driftsättning och omstrukturering av databasen.
Direkt till svaren
PostgreSQL
Delphi, PostgreSQL & FireDAC
Frågor om PostgreSQL-migrering, native drivrutiner, SQL-beteende och en lugn ombyggnad av dataåtkomst.
Direkt till svaren
Delphi REST
Delphi REST-API & REST-Server
Frågor om REST med Delphi, API-avgränsning, gemensam domänlogik och ren serverarkitektur.
Direkt till svaren
Tjänster
Windows- & Linux-tjänster
Frågor om bakgrundstjänster, schemaläggning, övervakning, återstartsbeteende och tydlig driftsavgränsning.
Direkt till svaren
Teknik
Delphi Multiplattform
Frågor om gemensam kodbas för Windows, macOS och Linux med kontrollerade plattformsgränser.
Direkt till svaren
Serverarkitektur
REST-Server & tjänster
Frågor om API:er, Windows- och Linux-tjänster, serverlogik, övervakning och driftansvar.
Direkt till svaren
Plattform
Windows 11 ARM64
Frågor om ny hårdvara, native beroenden, drivrutiner, byggen och utrullningsvägar.
Direkt till svaren
Projektstart
Projektstart, arkitektur & samarbete
Många första frågor handlar inte om en enskild teknik, utan om rätt startpunkt: Vad bör klargöras först, hur uppstår teknisk orientering och hur blir en idé till en robust och tillförlitlig start i ett verkligt projekt?
På startsidan dyker vanligen de första orienteringsfrågorna upp: Hur påbörjas ett projekt på ett meningsfullt sätt, vilka arkitekturfrågor bör klaras ut tidigt och när lönar sig modernisering istället för hetsig nyutveckling?
När lönar sig Delphi-modernisering istället för komplett nyutveckling?
När domänlogik, processer och datamodell är värdefulla är en kontrollerad ombyggnad ofta mer kostnadseffektiv än en nystart som innebär funktionsförlust och höga införanderisker.
Kan samma domänlogik drivas för Windows, macOS och Linux?
Ja. Särskilt i Delphi-projekt planerar vi gemensam affärslogik och separerar användargränssnitt, tjänster och dataåtkomst så att flera plattformar kan försörjas konsekvent.
Bygger Net-Base även REST-servrar och bakgrundstjänster?
Ja. Windows- och Linux-tjänster, REST-API:er, integrationsskikt och driftsättning hör för oss till arkitekturen och byggs inte på i efterhand.
Hur startar ett typiskt projekt?
Vanligtvis med en strukturerad inventering: mål, befintliga system, databas, plattformar, gränssnitt och driftrelaterade risker. Därav uppstår en startpunkt som realistiskt kan anpassas.
Ämnet i detalj
Om du från denna FAQ vill gå vidare till den fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Tjänster
Översikt över tjänster
På tjänstesidan uppstår vanligtvis de mest omfattande följdfrågorna: Vad tar vi konkret hand om, hur långt sträcker sig vårt tekniska ansvar och hur samverkar modernisering, integrationer, drift och vidareutveckling?
Särskilt för etablerade applikationer dyker ofta samma funktionella och tekniska frågor upp. Dessa punkter klargör vi tidigt, innan ett initiativ blir ett diffust storprojekt.
Tar ni också över befintliga Delphi-system?
Ja. Vi kliver regelbundet in i etablerade Delphi-applikationer, analyserar befintligt tillstånd, dataåtkomst, arkitektur och specialfall och bygger kontrollerat vidare på detta.
Kan REST-servrar, portaler och desktopklienter uppstå ur ett projekt?
Ja. Särskilt för företagsapplikationer planerar vi dessa komponenter medvetet tillsammans, så att samma affärslogik inte splittras i flera separata lösningar.
Är en BDE-ersättning möjlig även utan komplett utbyte?
I många fall ja. Vi separerar dataåtkomst, SQL och driftsättning stegvis från den gamla strukturen och bygger en native, underhållbar anslutning.
Stöder ni även drift och vidareutveckling?
Ja. Releaseprocesser, hosting, felanalys, databasunderhåll och senare utbyggnader är en del av vårt arbetsområde.
Ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupade ämnessidan hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Teknologier
Teknologi och arkitektur i översikt
Denna FAQ samlar de typiska orienteringsfrågorna för teknologival: När är Delphi starkt, när är C# den bättre byggstenen och hur sammanför en ren arkitektur flera plattformar, tjänster och klienter på ett kontrollerat sätt?
Teknologiska beslut måste passa teamet, domänen och driften. Just därför klargör vi dessa frågor inte abstrakt utan alltid med utgångspunkt i det konkreta systemet.
När är Delphi mer ändamålsenligt än en fullständig nyplattform?
Alltid när etablerad domänlogik, presterande skrivbordsprocesser och mål för flera plattformar bör föras vidare ekonomiskt, istället för att ersätta befintlig substans i onödan.
När använder ni dessutom C#?
Främst för portaler, webb-backends, REST-tjänster, integrationer och serviceorienterade arkitekturdelar som lätt kan integreras med befintliga skrivbordssystem.
Hur viktig är Layer-3 i praktiken?
Mycket. Först genom en tydlig separation av UI, affärslogik och dataåtkomst blir modernisering, tester, tjänster och framtida plattformsbyten hanterbara.
Bör nya plattformar som Windows 11 ARM64 beaktas tidigt?
Ja. Ny mål-hårdvara och distributionsvägar prövas tidigt, så att det senare inte blir kostsamma specialprojekt.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupade ämnessidan hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Projekt
Projektbilder och referensmönster
Den som besöker projektsidan vill oftast förstå vilken typ av åtaganden vi verkligen tar: engångsverktyg eller långlivade system med drift, behörighetskoncept, versioner, integrationer och verklig vidareutveckling.
Många projekt låter olika i början men har ändå gemensamma mönster: etablerad domänlogik, integrationer, behörigheter, versioner, driftfrågor och långsiktig utbyggbarhet.
Arbetar ni snarare med engångsverktyg eller med mer långlivade system?
Fokus ligger på system med drift, ansvar och vidareutveckling: företagsapplikationer, plattformar, tjänster, portaler och produktlogik.
Kan befintliga produkter eller interna system moderniseras parallellt?
Ja. Särskilt för länge etablerade system planerar vi ofta stegvis vidareutveckling så att drift och modernisering passar ihop.
Är hosting och teknisk drift en del av ert arbete?
Ja. Release, Hosting, Monitoring och driftsansvar ingår i vår projektplanering, så att den färdiga lösningen inte bara utvecklas utan också kan drivas hållbart.
Läs vidare om ämnet i detalj
Om du från denna FAQ går vidare till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Företagsprogramvara
Skräddarsydd företagsprogramvara & Layer-3
Dessa frågor uppstår typiskt när standardprogramvara inte längre räcker funktionellt och ett företag vill veta om ett skräddarsytt system verkligen kan byggas ekonomiskt, underhållsbart och utbyggbart.
Särskilt vid skräddarsydd företagsprogramvara handlar det inte bara om enstaka vyer, utan om roller, data, granskningsspår och en arkitektur som förblir rörlig även senare.
Är skräddarsydd företagsprogramvara bara meningsfull för mycket stora företag?
Nej. Den är motiverad när standardprogramvara endast kan avbilda processer med kringgående lösningar, informationsbrytningar eller dyra specialregler, och det verkliga värdet ligger i ren domänlogik.
Varför betonar ni Layer-3 så starkt vid företagsapplikationer?
Därför att först separationen mellan UI, affärslogik och dataåtkomst säkerställer att rapportering, nya klienter, tjänster och framtida utbyggnader förblir ekonomiskt hanterbara.
Kan ni också ta itu med befintliga ärvda processer?
Ja. Just då blir vårt arbete särskilt värdefullt eftersom vi gör domänprocesser, befintliga data och ärvd logik läsbara och därifrån utvecklar en hållbar målarkitektur.
Läs vidare om ämnet i detalj
Om du från denna FAQ går vidare till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Visa skräddarsydd företagsprogramvara & Layer-3-applikationer i detalj
Tjänster
Multiplattform med Delphi
Företag frågar här ofta inte bara efter en teknisk möjlighet utan efter en hållbar strategi: vilka delar förblir gemensamma, vad måste hanteras plattformsspecifikt och hur undviks dyr parallellutveckling?
Multiplattform blir först värdefullt när samma domänlogik förblir gemensam under kontrollerade former över flera målsystem och plattformssärdrag upptäcks tidigt.
Kan man med Delphi förutom Windows också inkludera macOS, Linux, iOS och Android?
Ja. Beroende på projektmål planerar vi desktopmål, mobila gränssnitt och servernära komponenter från en gemensam domänmässig linje, istället för att bygga om varje plattform funktionellt.
Hur förhindrar ni att multiplattformprojekt glider isär funktionellt?
Genom en gemensam kod- och arkitekturstrategi: affärsregler, datamodell och processer förblir centrala, medan plattformsspecifika skillnader medvetet kapslas in.
Är senare mobila utbyggnadsfaser fortfarande möjliga?
Ja. Om arkitektur, tjänster och gränssnitt är ordentligt förberedda kan iOS- eller Androidmål kopplas in senare på ett betydligt mer kontrollerat sätt.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där det större sammanhanget kring arkitektur, exempel, beslutsskäl och närliggande ämnen.
Tjänster
Tjänster, REST-servrar & portaler
Här måste behörigheter, dataflöden, loggning och domänregler hållas samman. Därför behandlar vi ämnet inte som en webbpåbyggnad, utan som en ordnad utbyggnad av samma applikationslinje.
Portaler, REST-API:er och tjänster fungerar bara bra om de inte placeras vid sidan av kärnsystemet, utan konsekvent för vidare samma data- och rolllogik.
Utvecklar ni både REST-servrar samt Windows- och Linux-tjänster?
Ja. Bakgrundstjänster, API:er, importer, exporter, portaler och teknisk driftslogik är återkommande uppgifter för oss.
När behöver en företagsapplikation dessutom en portal?
När kunder, partner eller interna roller behöver kontrollerad åtkomst till samma processer, utan att verksamhetsregler dupliceras i separata användargränssnitt.
Hur förblir behörigheter, loggning och processer konsekventa mellan klient och server?
Genom att inte dölja domänregler i enskilda endpunkter eller användargränssnitt, utan genom att skapa en tydlig domänlogisk mitt som klient, portal och tjänst kan använda gemensamt.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där det större sammanhanget kring arkitektur, exempel, beslutsskäl och närliggande ämnen.
Integration
Gränssnitt, dataflöden & plattformsmål
Dessa frågor uppstår ofta när datakvalitet, spårbarhet och framtida plattformsbyten blir viktigare än ren dataöverföring från A till B.
Gränssnitt framstår ofta som perifera frågor. I verkligheten avgör de datakvalitet, spårbarhet, plattformsbyten och stabil drift.
Kan befintliga gränssnitt och dataflöden förnyas utan Big Bang?
Ja. I många projekt ordnar vi om mappning, databasvägar, jobb och integrationer stegvis så att verkliga processer kan fortsätta.
Tar ni även hand om integrationer mot bokföring och tredjepartssystem?
Ja. Speciellt Fibu, API:er, CRM, lager, licenslogik eller branschspecifika tredjepartssystem måste vara väl dokumenterade, observerbara och verksamhetsmässigt kontrollerbart anslutna.
Tar ni plattformsmål som Windows 11 ARM64 med i integrationsprojekten redan från början?
Ja. Nya målplattformar, native beroenden och framtida deploymentsvägar hör tidigt in i samma planering som gränssnitt och dataflödeslogik.
Läs vidare om ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer detaljerade fackartikeln hittar du där det större sammanhanget med arkitektur, exempel, beslutsmotiv och närliggande ämnen.
Delphi
Delphi för företagsapplikationer
Här handlar det om principfrågan när Delphi fortfarande är ett medvetet arkitekturval och när andra komponenter bör komplettera eller ta över.
När det gäller Delphi i företag handlar det sällan om nostalgi, utan om hur inarbetad domänlogik, desktopprocesser och flera målplattformar kan fortsätta att drivas ekonomiskt och ordnat.
Varför satsar ni fortfarande medvetet på Delphi?
För att Delphi i många företagsapplikationer erbjuder en stark kombination av inarbetad affärslogik, högpresterande desktopprocesser, närhet till databasen och kontrollerbar vidareutveckling.
Är Delphi bara intressant för modernisering av befintliga system?
Nej. Delphi är också lämpligt för nya företagsapplikationer när produktiva desktopflöden, rapporter, lokal integration och en gemensam domänbas för flera plattformar är viktiga.
Var ligger begränsningarna för Delphi?
Särskilt där projektet i första hand är portal-, service- eller molncentrerat. Då kombinerar vi Delphi medvetet med C#, REST-servrar eller webbkomponenter istället för att tvinga allt in i ett verktyg.
Läs mer om ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer detaljerade fackartikeln hittar du där det större sammanhanget med arkitektur, exempel, beslutsmotiv och närliggande ämnen.
C#
C# för tjänster & portaler
Denna FAQ riktar sig till företag som inte ser C# som ett självändamål utan som en stark byggsten för portaler, API:er, integrationer och serviceorienterade arkitekturdelar.
C# är för oss särskilt starkt när webbportaler, API:er, tjänster, integrationer och en lugn driftprofil står i förgrunden.
När är C# ett bättre val jämfört med Delphi?
Särskilt när ett projekt i första hand består av REST-API:er, portaler, backendtjänster, integrationer eller molnnära driftsmodeller.
Använder ni C# även tillsammans med befintliga Delphi-system?
Ja. Just denna kombination är ofta lämplig: Delphi bär produktiv domänlogik i klienten, medan C# kompletterar tjänster, portaler och API-lager på ett tydligt sätt.
Vilka är typiska risker i C#-projekt?
Ofta byggs det tekniskt modernt för snabbt, utan att tidigt tydligt avgränsa roller, domänlogik, loggning, driftsättning och verkliga driftsfrågor. Just där fokuserar vi.
Läs mer om ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer detaljerade fackartikeln hittar du där det större sammanhanget med arkitektur, exempel, beslutsmotiv och närliggande ämnen.
Arkitektur
Layer-3-Arkitektur
Layer-3 förklaras ofta teoretiskt. I praktiken avgör denna struktur mycket direkt om nya klienter, tjänster, tester och tillägg kan ansluta smidigt eller orsaka kostsamma sprickor i arkitekturen.
Layer-3 är inte ett läroboksbegrepp, utan ett mycket praktiskt svar på växande monoliter, motsägelsefulla tillägg och kostsamma kopplingar i vardagen.
Varför är Layer-3 så viktigt för företagsapplikationer?
Därför att först en ren separation av UI, affärslogik och dataåtkomst säkerställer att tillägg, tester, tjänster och nya plattformar inte direkt misslyckas mot monoliten.
Är Layer-3 bara meningsfullt för stora projekt?
Nej. Särskilt medelstora system drar stor nytta av det, eftersom senare krav kan anslutas på ett betydligt mer kontrollerat sätt.
Vad är det vanligaste felet med Layer-3?
Att man bara ritar lagren formellt, medan de verkliga reglerna fortsätter att vara dolda i UI-koden eller direkt i SQL-särvägar. Då existerar uppdelningen bara på presentationsbilder, inte i systemet.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupade facksidan, hittar ni där den större kontexten med arkitektur, exempel, beslutsunderlag och närliggande ämnen.
Delphi-Team
Delphi-Utvecklare från Freiburg
Vid denna förfrågan handlar det sällan bara om en tillgänglig person. Vanligtvis står frågan om en partner verkligen kan ta över befintligt bestånd, domänlogik, dataåtkomst och den tekniska inriktningen på ett hållbart sätt.
Vid sökandet efter Delphi-utvecklare handlar det sällan bara om ledig kapacitet. Ofta gäller det en pålitlig övertagning av bestånd, arkitektur, dataåtkomst och verkligt domänansvar.
När är en extern Delphi-utvecklare lämplig?
Framför allt när kunskap om beståndet saknas, modernisering har stannat upp eller en applikation måste vidareutvecklas funktionellt utan att förlora sin substans.
Kan ni också gå in i etablerade Delphi-applikationer?
Ja. Det är just ett fokusområde: Vi analyserar äldre kod, databas, utrullning, specialfall och verksamhetsflöden och bygger kontrollerat vidare på det.
Handlar det bara om programmering eller även om den tekniska riktningen?
Det handlar uttryckligen också om riktning. Bra Delphi-utveckling inkluderar för oss arkitektur, dataåtkomst, integrationer, REST-tjänster och den verkliga driften.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupade facksidan, hittar ni där den större kontexten med arkitektur, exempel, beslutsunderlag och närliggande ämnen.
Förvaltning
Delphi-underhåll & förvaltning
Underhåll låter ofta mindre än vad det är. I praktiken handlar det om stabila releaser, synliga risker, teknisk ordning och frågan hur ett väletablerat system kan vidareutvecklas i lugn och ro.
Underhåll är i etablerade Delphi-system mer än buggfixning. Det berör releasesäkerhet, datakonsistens, teknisk skuld och frågan hur nya krav kan införas i befintlig lösning utan störningar.
Vad ingår i ett gott Delphi-underhåll?
Felanalys, vidareutveckling, databasunderhåll, releasehantering, teknisk dokumentation och en arkitektur som inte alltid gör nya krav dyrare.
Kan stöd börja utan en komplett ombyggnad?
Ja. Ofta börjar det med stabilisering, att synliggöra risker och en prioriterad lista över tekniska och verksamhetsrelaterade förbättringar.
Hur minskar ni beroendet av enskild kunskap?
Genom att vi strukturerat dokumenterar datavägar, komponenter, build-steg och kritisk verksamhetslogik, och gör implicit kunskap till spårbar systemlogik.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupande facksidan, hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och angränsande frågor.
Modernisering
Delphi-Modernisering
Dessa svar hjälper framför allt där en äldre applikation fortfarande är stark ur verksamhetens perspektiv, men tekniskt har samlat för många flaskhalsar för att bära nya krav på ett stabilt sätt.
Den kritiska punkten vid modernisering är sällan bara ytan. Vanligtvis rör det sig om verksamhetslogik, data, beroenden och en migrationsstrategi som fungerar i löpande drift.
Måste en gammal Delphi-applikation ersättas helt?
Nej. Ofta är en kontrollerad ombyggnad mer ändamålsenlig: uppdatera dataåtkomst, koppla loss logik, lägga till tjänster och målmedvetet modernisera gränssnitt.
Hur undviker man driftstörningar vid modernisering?
Genom tydliga mellansteg, rena gränssnitt och en migrationsväg där gamla och nya delar kan samexistera kontrollerat.
Kan befintlig verksamhetslogik senare flyttas över till tjänster eller portaler?
Ja. Precis därför lösgör vi affärslogik från UI-nära äldre kod och för den till en struktur som klienter, tjänster och API:er kan använda gemensamt.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill gå vidare till den fördjupande facksidan, hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och angränsande frågor.
Dataåtkomst
BDE-ersättning
BDE är sällan bara en föråldrad komponent. Den är ofta bunden till historisk SQL-logik, databasantaganden och distributionsvägar. Precis därför behandlar vi ämnet här medvetet något bredare.
Den BDE är sällan bara en enskild teknisk komponent. Den är kopplad till SQL, utrullning, drivrutiner, teckenuppsättningar och historiska sidoeffekter. Därför behandlar vi ersättningen som ett moderniseringssteg och inte som ett komponentbyte.
Är ett byte till FireDAC eller native-drivrutiner möjligt utan helombyggnad?
Ja, ofta i etapper. Det är viktigt att noggrant granska SQL, datatyper, transaktioner och specialfall, istället för att bara ersätta komponenter 1:1.
Varför berör BDE-ersättningen nästan alltid även databasstrukturen?
Därför att gamla tabeller, index, teckenuppsättningar och historiskt uppkomna SQL-vägar ofta blir synliga, och dessa bör rensas upp för stabilitet och prestanda.
Vad vinner man konkret med native databasanslutning?
Enklare utrullning, bättre underhåll, kontrollerbara anslutningar och en avsevärt bättre grund för tjänster, API:er och framtida utvidgningar.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den som använder PostgreSQL och BDE-Ablosung mit nativer Anbindung vill ofta mer än bara en ny komponent. Bakom ligger ofta frågan hur dataåtkomst, SQL, utrullning och befintlig logik återförs till en hållbar linje.
Med PostgreSQL och FireDAC handlar det inte bara om en ny anslutningskomponent. Oft innebär det ett större steg mot mer robust SQL, bättre utrullning och kontrollerad datahantering.
När är PostgreSQL ett bra val för Delphi?
När stabilitet, fleranvändarmiljö, tydliga SQL-flöden, öppen infrastruktur och ren utbyggbarhet för stationära klienter, tjänster eller portaler är viktiga.
Är FireDAC alltid rätt väg?
FireDAC är ofta en mycket bra väg, men inte som ett blint byte. Avgörande är SQL-beteende, datatyper, transaktioner, felvägar och det konkreta beståndet.
Kan BDE-, Paradox- eller gamla SQL-system successivt migrera till PostgreSQL?
Ja. I många fall är en kontrollerad stegvis väg ekonomiskt fördelaktigare än ett hårt avbrott, så länge datamodell och domänlogik beaktas noggrant.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Delphi REST
Delphi REST-API & REST-Server
Denna FAQ besvarar den typiska principiella frågan om REST med Delphi bara är ett tekniskt tillägg eller en seriös serverstrategi. Avgörande är alltid hur väl klient, regler, data och drift hålls ihop.
REST mit Delphi wird stark, wenn APIs nicht losgelöst neben dem Bestand stehen, sondern Rechte, Business-Logik, Datenmodell und Betrieb sauber mittragen.
Kan man med Delphi bygga produktiva REST-API:er?
Ja. Särskilt när samma domänlogik redan finns i Delphi-beståndet är en väl avgränsad REST-server ofta mer kostnadseffektiv än en helt ny parallell värld.
När lönar sig en REST-server jämfört med direkt databasåtkomst?
Så snart flera klienter, portaler, tjänster eller integrationer ska använda samma regler kontrollerat och direkt SQL‑åtkomst blir för riskabelt ur verksamhetssynpunkt.
Hur håller ni Delphi-klient och REST konsistenta?
Genom en arkitektur där affärsregler inte döljs i formulär utan kan användas gemensamt av klient, API och bakgrundsprocesser.
Läs ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Tjänster
Windows- & Linux-tjänster
När det gäller tjänster handlar det sällan bara om en körande process. Viktigare är loggning, observabilitet, automatisk omstart, datakonsistens och den sakliga frågan vilka delar hör hemma i bakgrunden och vilka inte.
Bakgrundstjänster är ofta den osynliga kärnan i ett system. De måste köras stabilt, hantera tillståndsövergångar korrekt och passa robust in i driften med loggning, omstart och övervakning.
När behöver en företagsapplikation dessutom Windows- eller Linux-tjänster?
Alltid när importer, exporter, schemaläggning, synkronisering, licenslogik eller integrationer inte ska vara bundna till en inloggad skrivbordsmiljö.
Kan tjänster och REST komma från samma arkitektur?
Ja. Precis det är ofta meningsfullt eftersom affärslogik, datamodell och loggning därigenom inte sprids ut i flera tekniska öar.
Vad är särskilt viktigt för produktiva tjänster?
Tydlig felhantering, observerbara tillstånd, omstartssäkerhet, loggning, deployment och en verksamhetsmässigt konsekvent bearbetning istället för tyst bakgrundsmagi.
Läs ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Teknik
Delphi Multiplattform
Denna FAQ belyser den tekniska sidan av multiplattformsstrategin: kodbas, paketering, systemnähet, releaseprocesser och frågan när flera klienter verkligen blir lönsamma.
Multiplattform fungerar bara ordentligt om kodbas, datamodell, plattformsförskillnader och deployment planeras medvetet. Precis där uppstår det egentliga projektvärdet.
Kan samma applikation verkligen köras på Windows, macOS och Linux?
Ja, om gränssnitt, domänlogik, plattformsspecifika särdrag och releaseprocesser inte blandas utan hålls tydligt åtskilda.
Vad är det vanligaste misstaget i multiplattformsprojekt?
Att fundera för sent över filsystem, utskrift, signering, målplattformar, paketering och gränssnittsskillnader. Då blir multiplattform snabbt dyrt och inkonsekvent.
Kan tjänster och API:er använda samma domänlogik?
Ja. En god arkitektur säkerställer att inte varje plattform utvecklar sin egen avvikande domänlogik.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Serverarkitektur
REST-servrar & tjänster
När API:er och tjänster bara låter tekniskt moderna men inte är tydligt avgränsade funktionellt, blir de snabbt ett problem. Denna FAQ placerar just dessa beslut i sitt sammanhang.
Många system misslyckas inte med API-idén utan med att serverlogik senare improviseras ovanpå en befintlig skrivbordskodbas. Vi planerar dessa delar medvetet tillsammans.
När behöver en företagsapplikation dessutom en REST-server?
Så snart flera klienter, portaler, mobila åtkomster, externa integrationer eller fristående processer ska kontrollerat använda samma domänlogik.
Stödjer ni även Windows- och Linux-tjänster?
Ja. Bakgrundsprocesser, schemaläggning, synkronisering, exporter, licenstjänster och tekniska stödfunktioner hör till våra typiska uppgifter.
Hur bevaras domänkonsistensen mellan klient, REST och tjänst?
Genom en arkitektur där affärsregler inte göms i enskilda gränssnitt utan förblir gemensamt åtkomliga och spårbara.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Plattform
Windows 11 ARM64
ARM64 påverkar många applikationer tidigare än väntat. Denna FAQ svarar på typiska frågor kring beroenden, tester, installationsprogram och den ekonomiska bedömningen av ny mål-hårdvara.
ARM64 är inte längre ett exotiskt sidotema utan en verklig målplattform. Den som tänker på den tidigt undviker senare tekniska återvändsgränder i deployment och vid native beroenden.
Varför bör Windows 11 ARM64 beaktas redan idag?
För att nya hårdvaruklasser och mobila arbetsplatser i ökande utsträckning bygger på den, och teknisk efterarbete senare blir avsevärt dyrare än ett tidigt arkitekturval.
Vad är särskilt kritiskt när det gäller Delphi och nativeberoenden på ARM64?
Särskilt externa bibliotek, databasdrivrutiner, installationsprogram, setup-processer och tester på faktisk målmaskinvara måste verifieras tidigt.
Måste det för ARM64 skapas en helt separat produkt?
Inte nödvändigtvis. Ofta räcker det att noggrant förbereda build- och deployment-pipelines och att i god tid avkoppla kritiska nativeberoenden.
Läs vidare om ämnet i detalj
Om ni vill gå från denna FAQ till den mer fördjupade facksidan hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Ska en FAQ leda till ett konkret projektsamtal?
Då är nästa rimliga steg inte ännu en samling nyckelord, utan en strukturerad kartläggning av er befintliga lösning: Vilken domänlogik finns, var bromsar den nuvarande arkitekturen, vilka gränssnitt är kritiska och vilken utbyggnadsstrategi är tekniskt hållbar?
Nästa steg
Om ni har en konkret fråga om modernisering, API eller plattform, bör vi tidigt tydligt fastställa den tekniska avgränsningen.
Net-Base utvärderar befintliga system, datavägar, gränssnitt och målplattformar inte isolerat, utan i samband med domänlogik, drift och senare utbyggnad.
- Nuläge, målbild och tekniska risker bedöms tillsammans.
- REST, dataåtkomst, portaler och utrullning skjuts inte upp som sena följder.
- Ni ser tidigt vilken väg som är ekonomiskt och driftsmässigt bärkraftig.