Frågor och svar
Översikt över centrala FAQ
Lämpliga prestanda- och teknikvägar
Viktiga fördjupningar i detta ämne
FAQ-landningssida
Centrala frågor och svar om projektstart, tjänster, företagsmjukvara, Delphi, arkitektur, portaler, tjänster och modernisering.
Denna sida samlar de vanligaste frågorna från vår startsida, översiktssidorna och de ämnesspecifika undersidorna på ett ställe. De kompakta FAQ:erna finns medvetet kvar på respektive detaljsida. Här organiserar vi dem dessutom som en landningssida, så att intressenter snabbt kan se vilka ämnen vi verkligen behärskar inom Projektstart — Architektur & Zusammenarbeit, tjänster, Delphi, C#, Layer-3, portaler, modernisering, dataåtkomst och plattformsstrategi.
Du kan antingen hoppa direkt till en ämnessektion eller byta till respektive fördjupningssida nedan. På så sätt fungerar sidan både som en snabb startpunkt och som en strukturerad FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbete
Frågor om en meningsfull start, inventering och tidiga arkitekturbeslut.
Direkt till svaren
Tjänster
Översikt över tjänster
Frågor om övertagande av befintliga system, modernisering, tjänster, dataåtkomst och långsiktigt underhåll.
Direkt till svaren
Teknologier
Teknologi och arkitektur i överblick
Frågor om Delphi, C#, Layer-3, plattformsval och den tekniska linjen över flera utbyggnadssteg.
Direkt till svaren
Projekt
Projektbilder och referensmönster
Frågor om projektstorlek, driftsansvar, hosting, produktlogik och system med längre livslängd.
Direkt till svaren
Företagsmjukvara
Skräddarsydd företagsmjukvara & 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 baserade på 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 av UI, affärslogik och dataåtkomst och varför det är direkt ekonomiskt relevant.
Direkt till svaren
Delphi-team
Delphi-Utvecklare från Freiburg
Frågor om extern support, övertagande av befintliga system och tekniskt ansvar i etablerade Delphi-system.
Direkt till svaren
Support
Delphi-Underhåll & Support
Frågor om stabilisering, vidareutveckling, release-säkerhet och minskning av enskild kunskap.
Direkt till svaren
Modernisering
Delphi-Modernisering
Frågor om ombyggnadsplan, risk, bevarande av domänlogik och stegvis förnyelse i löpande drift.
Direkt till svaren
Dataåtkomst
BDE-Utfasning
Frågor om FireDAC, native drivrutiner, SQL-särskildheter, deployment och omstrukturering av databasen.
Direkt till svaren
PostgreSQL
Delphi, PostgreSQL & FireDAC
Frågor om PostgreSQL-migration, native drivrutiner, SQL-beteende och en lugn ombyggnad av dataåtkomsten.
Direkt till svaren
Delphi REST
Delphi REST-API & REST-Server
Frågor om REST med Delphi, API-design, gemensam domänlogik och ren serverarkitektur.
Direkt till svaren
Tjänster
Windows- & Linux-Services
Frågor om bakgrundstjänster, schemaläggning, övervakning, omstartsbeteende och en tydlig driftindelning.
Direkt till svaren
Teknologi
Delphi Multiplattform
Frågor om en 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, builds och utrullningsvägar.
Direkt till svaren
Projektstart
Projektstart, arkitektur & samarbete
Många inledande frågor handlar inte om en enskild teknologi, utan om rätt startpunkt: Vad bör man klargöra först, hur uppstår teknisk orientering och hur blir en idé en pålitlig ingång till ett verkligt projekt?
På startsidan dyker vanligtvis de första orienteringsfrågorna upp: Hur påbörjar man ett projekt på ett vettigt sätt, vilka arkitekturfrågor bör man tidigt klarlägga och när är modernisering att föredra framför hetsig nyutveckling?
När är Delphi-modernisering att föredra framför en komplett nyutveckling?
När affärslogik, processer och datamodell är värdefulla är en kontrollerad ombyggnad ofta mer ekonomisk än en nystart som innebär funktionsförluster och höga införanderisker.
Kan samma affärslogik användas för Windows, macOS och Linux?
Ja. Särskilt i Delphi-projekt planerar vi gemensam affärslogik och separerar presentation, tjänster och dataåtkomst så att flera plattformar kan förses på ett rent sätt.
Bygger Net-Base också REST-servrar och bakgrundstjänster?
Ja. Windows- och Linux-tjänster, REST-API:er, integrationslager och deployment hör för oss till arkitekturen och läggs inte på i efterhand.
Hur startar ett typiskt projekt?
Vanligtvis med en strukturerad inventering: mål, befintliga system, databas, plattformar, gränssnitt och driftsrisker. Därav växer fram en realistiskt anpassningsbar startpunkt.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där den större sammanhangen med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Tjänster
Tjänster i översikt
På tjänstesidan uppstår ofta de mest omfattande återfrågorna: Vad tar vi konkret ansvar för, hur långt sträcker sig vårt tekniska ansvar och hur samverkar modernisering, integrationer, drift och vidareutveckling?
Särskilt i växande befintliga applikationer dyker ofta samma fackliga och tekniska frågor upp. Dessa punkter klargör vi tidigt, innan ett initiativ blir ett otydligt storskaligt projekt.
Tar ni även över befintliga Delphi-system?
Ja. Vi går regelbundet in i växande Delphi-applikationer, analyserar befintligt system, dataåtkomst, arkitektur och specialfall och bygger vidare kontrollerat på detta.
Kan REST-servrar, portaler och desktopklienter skapas inom ett projekt?
Ja. Särskilt för företagsapplikationer planerar vi dessa komponenter medvetet tillsammans, så att samma affärslogik inte splittras i flera speciallösningar.
Är en BDE-avlösning möjlig även utan fullständigt utbyte?
I många fall ja. Vi löser dataåtkomst, SQL och deployment stegvis ur den gamla strukturen och bygger en native, underhållbar anslutning.
Stöder ni även drift och vidareutveckling?
Ja. Releaseprocesser, hosting, felsökning, databasunderhåll och senare utbyggnader ingår i vår arbetsbild.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där den större helheten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Teknologier
Teknologi och arkitektur i översikt
Denna FAQ sammanför typiska orienteringsfrågor inför teknologival: När är Delphi stark, när är C# den bättre byggstenen och hur förenar en ren arkitektur flera plattformar, tjänster och klienter på ett kontrollerat sätt?
Teknologiska beslut måste passa teamet, funktionaliteten och driften. Just därför utreder vi dessa frågor inte abstrakt, utan alltid utifrån det konkreta systemet.
När är Delphi motiverat jämfört med en helt ny plattform?
Alltid när väletablerad domänlogik, högpresterande desktopprocesser och multiplattformsmål ska föras vidare på ett ekonomiskt försvarbart sätt, istället för att ersätta kärnan lättvindigt.
När använder ni dessutom C#?
Främst för portaler, webbbackends, REST-tjänster, integrationer och serviceorienterade arkitekturdelar som låter sig väl integreras med befintliga desktopsystem.
Hur viktig är Layer-3 i praktiken?
Mycket. Endast en tydlig separation av UI, affärslogik och dataåtkomst gör modernisering, tester, tjänster och framtida plattformsbyten hanterbara.
Beaktar ni nya målplattformar som Windows 11 ARM64 i ett tidigt skede?
Ja. Ny målmaskinvara och distributionsvägar granskas tidigt, så att de senare inte blir kostsamma specialprojekt.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där den större helheten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Projekt
Projektbilder och referensmönster
Den som tittar på projektsidan vill ofta förstå vilken typ av projekt vi faktiskt tar på oss: 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: väletablerad domänlogik, integrationer, behörigheter, versioner, driftsfrågor och långsiktig utbyggbarhet.
Arbetar ni hellre med engångsverktyg eller med långsiktigt bärkraftiga system?
Fokus ligger på system med livstid, 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 befintliga system planerar vi ofta en stegvis vidareutveckling, så att drift och modernisering passar ihop.
Ingår hosting och teknisk drift i ert arbete?
Ja. Releasehantering, hosting, monitoring och driftansvar ingår i vår projektplanering, så att den färdiga lösningen inte bara utvecklas utan också kan drivas på ett hållbart sätt.
Läs mer om ämnet i detalj
Om du vill byta från denna FAQ till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Företagsprogramvara
Individuell företagsprogramvara & Layer-3
Dessa frågor uppstår typiskt när standardprogramvara inte längre räcker ur facklig synvinkel och ett företag vill veta om ett individuellt system verkligen kan byggas kostnadseffektivt, underhållsbart och med goda utbyggnadsmöjligheter.
Särskilt för individuell företagsprogramvara handlar det inte bara om enskilda gränssnitt, utan om roller, data, granskningsspår och en arkitektur som förblir flexibel även framöver.
Är individuell företagsprogramvara bara meningsfull för mycket stora företag?
Nej. Den lönar sig alltid när standardprogramvara bara kan täcka processer med omvägar, medieavbrott eller dyra specialregler, och det verkliga värdet ligger i ren domänlogik.
Varför betonar ni Layer-3 så starkt i företagsapplikationer?
Därför att först separationen av användargränssnitt (UI), affärslogik och dataåtkomst säkerställer att rapportering, nya klienter, tjänster och framtida utvidgningar förblir ekonomiskt kontrollerbara.
Kan ni även arbeta med etablerade, historiskt uppbyggda processer?
Ja. Särskilt då blir vårt arbete kraftfullt, eftersom vi gör fackprocesser, befintliga data och äldre logik läsbara och utvecklar därifrån en hållbar målarkitektur.
Läs mer om ämnet i detalj
Om du vill byta från denna FAQ till den mer fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Se individuell 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 robust strategi: Vilka delar förblir gemensamma, vad måste hanteras plattformsspecifikt och hur undviker man dyrt parallellbygge?
Multiplattform blir först värdefullt när samma domänlogik förblir kontrollerat gemensam över flera målplattformar och plattformsanpassningar synliggörs i ett tidigt skede.
Kan man med Delphi utöver Windows även ta med macOS, Linux, iOS och Android?
Ja. Beroende på projektmålet planerar vi desktopmål, mobila gränssnitt och servernära komponenter utifrån en gemensam domänlogisk linje, istället för att återskapa den funktionella logiken för varje plattform.
Hur undviker ni att multiplattformsprojekt glider isär funktionellt?
Genom en gemensam kod- och arkitekturstrategi: domänregler, datamodell och processer förblir centrala, medan plattformsspecifika skillnader medvetet kapslas in.
Är mobila utbyggnadssteg möjliga även senare?
Ja. Om arkitektur, tjänster och gränssnitt är väl förberedda kan iOS- eller Android-mål anslutas senare på ett betydligt mer kontrollerat sätt.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Tjänst
Tjänster, REST-servrar & portaler
Precis här måste åtkomsträttigheter, dataflöden, loggning och fackregler hållas samman. Därför behandlar vi ämnet inte som ett webbtillägg, utan som en ordnad utbyggnad av samma applikationslinje.
Portaler, REST-API:er och tjänster fungerar endast väl om de inte ligger vid sidan av kärnsystemet, utan konsekvent bär vidare samma data- och rollogik.
Utvecklar ni både REST-servrar och Windows- och Linux-tjänster?
Ja. Bakgrundstjänster, API:er, importer, exporter, portaler och teknisk driftslogik är återkommande uppdrag för oss.
När behöver en företagsapplikation dessutom en portal?
När kunder, partners eller interna roller behöver kontrollerad åtkomst till samma processer, utan att man duplicerar fackregler i separata gränssnitt.
Hur förblir rättigheter, loggning och processer konsistenta mellan klient och server?
Genom att vi inte döljer fackregler i enskilda endpunkter eller användargränssnitt, utan skapar en tydlig facklig mitt som klient, portal och tjänst kan använda gemensamt.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder 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 datatransfer från A till B.
Gränssnitt framstår ofta som sidoämnen. 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 omstrukturerar vi mappning, databasvägar, jobb och integrationer stegvis så att de faktiska processerna kan fortsätta.
Tar ni även hand om redovisnings- och tredjepartssystemintegrationer?
Ja. Särskilt redovisning, API:er, CRM, lager, licenslogik eller branschspecifika tredjepartssystem måste anslutas med god dokumentation, vara övervakbara och funktionellt kontrollerbara.
Tänker ni på plattforms‑mål som Windows 11 ARM64 i sådana integrationsprojekt redan från början?
Ja. Nya målplattformar, native beroenden och framtida deploy‑vägar bör tidigt ingå i samma planering som gränssnitt och dataflödeslogik.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den mer fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Delphi
Delphi för företagsapplikationer
Här handlar det om grundfrågan när Delphi fortfarande är ett medvetet arkitekturval och när andra byggstenar lämpligen bör komplettera eller ta över.
När det gäller Delphi handlar det i företag sällan om nostalgi, utan om frågan hur etablerad domänlogik, desktopprocesser och flera målplattformar kan fortsättas på ett ekonomiskt och strukturerat sätt.
Varför väljer ni fortfarande medvetet Delphi?
För att Delphi i många företagsapplikationer erbjuder en stark kombination av etablerad affärslogik, högpresterande desktopprocesser, närhet till databasen och kontrollerbar vidareutveckling.
Är Delphi endast intressant för modernisering av befintliga system?
Nej. Delphi är också lämpligt för nya företagsapplikationer när produktiva desktopprocesser, rapporter, lokal integration och en gemensam domänbas för flera plattformar är viktiga.
Var ligger begränsningarna för Delphi?
Framför allt där ett projekt är primärt portal-, service- eller molncentrerat. Då kombinerar vi Delphi medvetet med C#, REST-servrar eller webbkomponenter istället för att försöka pressa allt in i ett verktyg.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den mer fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
C#
C# för tjänster & portaler
Denna FAQ riktar sig till företag som vill förstå C# inte 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 framför allt starkt när webbportaler, API:er, tjänster, integrationer och en stabil driftsmodell står i förgrunden.
När är C# jämfört med Delphi det bättre valet?
Framför allt när ett projekt primärt 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# på ett tydligt sätt kompletterar tjänster, portaler och API-lager.
Vilka är typiska risker i C#-projekt?
Ofta byggs det tekniskt modernt för snabbt, utan att roller, domänlogik, loggning, deployment och verkliga driftsfrågor renodlas i tid. Precis där går vi in.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den mer fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Arkitektur
Layer-3-Arkitektur
Layer-3 förklaras ofta teoretiskt. I praktiken avgör dock denna struktur mycket direkt om nya klienter, tjänster, tester och tillägg kan anslutas stabilt eller om de blir kostsamma och splittrade.
Layer-3 är inget 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?
Först när UI, affärslogik och dataåtkomst är tydligt åtskilda säkerställs att tillägg, tester, tjänster och nya plattformar inte misslyckas direkt vid monoliten.
Är Layer-3 bara meningsfullt för stora projekt?
Nej. Särskilt medelstora system drar stor nytta av det, eftersom framtida krav då kan anslutas betydligt mer kontrollerat.
Vilket är det vanligaste felet med Layer-3?
Att man bara ritar upp lager formellt, medan de egentliga reglerna fortfarande ligger gömda i UI-koden eller i särskilda SQL-vägar. Då finns strukturen bara på slides, inte i systemet.
Läs vidare om ämnet i detalj
Om du från denna FAQ vill gå vidare till den fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutskriterier och närliggande ämnen.
Delphi-team
Delphi-utvecklare från Freiburg
Vid denna typ av förfrågan handlar det sällan bara om en tillgänglig person. Vanligtvis rör det sig om frågan huruvida en partner verkligen kan ta över befintlig kodbas, domänlogik, dataåtkomst och den tekniska riktningen på ett hållbart sätt.
Vid sökandet efter Delphi-utvecklare handlar det sällan bara om ledig kapacitet. Det gäller oftare en pålitlig övertagning av befintlig kodbas, arkitektur, dataåtkomst och verkligt fackligt ansvar.
När är en extern Delphi-utvecklare meningsfull?
Särskilt när kunskap om det befintliga systemet saknas, när moderniseringen har stannat upp eller när en applikation måste vidareutvecklas fackligt utan att dess substans går förlorad.
Kan ni också kliva in i befintliga Delphi-applikationer?
Ja. Precis detta är ett fokusområde: Vi analyserar befintlig kod, databas, driftsättning, specialfall och fackliga processer och bygger kontrollerat vidare på det.
Handlar det bara om programmering eller också om teknisk riktning?
Det handlar uttryckligen också om riktning. God Delphi-utveckling omfattar för oss arkitektur, dataåtkomst, integrationer, REST-tjänster och den faktiska driften.
Läs vidare om ämnet i detalj
Om du från denna FAQ vill gå vidare till den fördjupade facksidan hittar du där den större kontexten med arkitektur, exempel, beslutskriterier och närliggande ämnen.
Betreuung
Delphi-Underhåll & Support
Underhåll låter ofta mindre än 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 vid väletablerade Delphi-system mer än att bara åtgärda buggar. Det rör releassäkerhet, datakonsistens, teknisk skuld och frågan hur nya krav kan integreras i befintlig kodbas utan störningar.
Vad ingår i ett bra Delphi-underhåll?
Felanalys, vidareutveckling, databashantering, release-stöd, teknisk dokumentation och en arkitektur som inte alltid gör nya krav dyrare.
Kan ett löpande underhåll starta utan komplett ombyggnad?
Ja. Ofta börjar det med stabilisering, att synliggöra risker och en prioriterad lista över tekniska och funktionella förbättringar.
Hur minskar ni beroendet av individuell kunskap?
Genom att vi strukturerat dokumenterar dataflöden, komponenter, byggsteg och kritisk domänlogik och återför implicit kunskap till spårbar systemlogik.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsunderlag och närliggande ämnen.
Modernisering
Delphi-modernisering
Dessa svar hjälper särskilt där en äldre applikation fortfarande är stark funktionellt, men tekniskt har samlat för många flaskhalsar för att rent bära nya krav.
Den kritiska punkten vid modernisering är sällan bara användargränssnittet. Vanligtvis handlar det om domänlogik, data, beroenden och en migrationsstrategi som fungerar i daglig drift.
Måste en gammal Delphi-applikation ersättas helt?
Nej. Ofta är en kontrollerad ombyggnad mer lämplig: förnya dataåtkomst, koppla loss logik, komplettera med tjänster och modernisera gränssnitt riktat.
Hur undviker man avbrott i driften vid modernisering?
Genom tydliga mellansteg, rena gränssnitt och en migrationsväg där gamla och nya delar kontrollerat kan samexistera.
Kan befintlig domänlogik senare överföras till tjänster eller portaler?
Ja. Just därför separerar vi affärslogik från UI-nära gammal kod och placerar den i en struktur som klienter, tjänster och API:er kan dela.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där den större kontexten med arkitektur, exempel, beslutsunderlag och närliggande ämnen.
Dataåtkomst
BDE-ersättning
BDE är sällan bara en gammal drivrutin. Den hänger vanligen ihop med historisk SQL-logik, databassantaganden och deploymentsvägar. Just därför behandlar vi ämnet här medvetet något bredare.
BDE är sällan bara en enskild teknisk komponent. Den hänger ihop med SQL, deployment, 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 komplett ombyggnad?
Ja, ofta i steg. Viktigt är att noggrant granska SQL, datatyper, transaktioner och specialfall, istället för att bara ersätta komponenter 1:1.
Varför påverkar BDE-ersättningen nästan alltid även databasstrukturen?
För att ofta blir gamla tabeller, index, teckenuppsättningar och historiskt uppkomna SQL-vägar synliga, vilka bör åtgärdas i samband med detta för stabilitet och prestanda.
Vad vinner man konkret med native databasanslutning?
Enklare deployment, bättre underhållbarhet, kontrollerbara anslutningar och en klart bättre grund för tjänster, API:er och framtida utvidgningar.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där den större kontexten kring arkitektur, exempel, beslutsgrunder och angränsande ämnen.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den som använder PostgreSQL och BDE-Ablosung mit nativer Anbindung vill oftast mer än bara en ny komponent. Bakom ligger ofta frågan hur dataåtkomst, SQL, deployment och befintlig verksamhetslogik återförs till en hållbar linje.
Med PostgreSQL och FireDAC handlar det inte bara om en ny anslutningskomponent. Vanligtvis ligger bakom det ett större steg mot mer robust SQL, bättre deployment 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 desktop, 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 utbyte. Avgörande är SQL-beteende, datatyper, transaktioner, felvägar och det konkreta beståndet.
Kan BDE-, Paradox- eller gamla SQL-system stegvis 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 vidare om ämnet i detalj
Om du vill gå från denna FAQ till den mer djupgående facksidan hittar du där den större kontexten kring arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Delphi REST
Delphi REST-API & REST-Server
Denna FAQ besvarar den typiska grundfrågan om REST med Delphi är bara 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 med Delphi blir starkt när API:er inte ligger lösgjorda vid sidan av den befintliga lösningen, utan bär rättigheter, affärslogik, datamodell och drift på ett tydligt sätt.
Kan man bygga produktiva REST-API:er med Delphi?
Ja. Särskilt när samma domänlogik redan finns i Delphi-beståndet, är en väl avgränsad REST-server ofta mer ekonomisk än att skapa en helt ny parallel värld.
När lönar sig en REST-server jämfört med direkt databasåtkomst?
När flera klienter, portaler, tjänster eller integrationer ska använda samma regler på ett kontrollerat sätt och direkt SQL-åtkomst blir för riskabelt ur funktionellt hänseende.
Hur håller ni Delphi-klient och REST konsekventa?
Genom en arkitektur där affärsregler inte döljs i formulär, utan görs gemensamt tillgängliga för klient, API och bakgrundsprocesser.
Läs ämnet i detalj
Om ni vill gå från denna FAQ till den fördjupade ämnessidan hittar ni där den större kontexten kring arkitektur, exempel, beslutsunderlag 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, observerbarhet, återstart, datakonsistens och den domänmässiga frågan vilka delar som hör hemma i bakgrunden och vilka som inte gör det.
Bakgrundstjänster är ofta systemets osynliga kärna. De måste köras stabilt, hantera tillståndsövergångar korrekt och passa robust in i driften med loggning, återstart och övervakning.
När behöver en företagsapplikation dessutom Windows- eller Linux-tjänster?
När import, export, schemaläggning, synkronisering, licenslogik eller integrationer inte ska vara bundna till en inloggad desktop.
Kan tjänster och REST komma från samma arkitektur?
Ja. Det är ofta vettigt, eftersom affärslogik, datamodell och loggning då inte splittras över flera tekniska öar.
Vad är särskilt viktigt för produktiva tjänster?
Tydlig felhantering, observerbara tillstånd, återstartssäkerhet, loggning, driftsättning och en domänmässigt konsekvent bearbetning i stället för tyst bakgrundsmagi.
Läs ämnet i detalj
Om ni vill gå från denna FAQ till den fördjupade ämnessidan hittar ni där den större kontexten kring arkitektur, exempel, beslutsunderlag och angränsande ämnen.
Teknologi
Delphi Multiplattform
Denna FAQ belyser den tekniska sidan av multiplattformsstrategin: kodbas, paketering, systemsnära aspekter, release-processer och frågan när flera klienter verkligen blir ekonomiskt motiverade.
Multiplattform fungerar bara riktigt väl om kodbas, datamodell, plattformsdifferenser och driftsättning är medvetet planerade. Det är där det verkliga projektvärdet uppstår.
Kan samma applikation verkligen köras på Windows, macOS och Linux?
Ja, om användargränssnitt, domänlogik, plattformsspecifika särdrag och releaseprocesser inte blandas utan struktureras tydligt.
Vad är det vanligaste misstaget i multiplattformsprojekt?
Att tänka på filsystem, utskrift, signering, målplattformar, paketering och UI‑skillnader för sent. Då blir multiplattform snabbt dyrt och inkonsekvent.
Kan tjänster och API:er använda samma domänlogik?
Ja. En bra arkitektur säkerställer att inte varje plattform utvecklar sin egen domänspecifika lösning.
Läs ämnet i detalj
Om du går från denna FAQ till den fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande frågor.
Serverarkitektur
REST-servrar & tjänster
Om API:er och tjänster bara låter tekniskt moderna men saknar ett tydligt domänmässigt snitt blir de snabbt ett problem. Denna FAQ sätter dessa beslut i sitt sammanhang.
Många system misslyckas inte på grund av API‑idén, utan för att serverlogik senare improviseras och fästs vid befintlig desktopkod. Vi planerar dessa delar medvetet tillsammans.
När behöver en företagsapplikation ytterligare en REST-server?
När flera klienter, portaler, mobila åtkomster, externa integrationer eller avkopplade processer behöver använda samma domänlogik under kontrollerade former.
Stöder ni även Windows- och Linux-tjänster?
Ja. Bakgrundsprocesser, schemaläggning, synkronisering, exporter, licenstjänster och tekniska följdprocesser är typiska uppgifter för oss.
Hur upprätthålls den domänmässiga konsistensen mellan klient, REST och tjänst?
Genom en arkitektur där affärsregler inte göms i enskilda gränssnitt, utan förblir gemensamma, återanvändbara och spårbara.
Läs ämnet i detalj
Om du går från denna FAQ till den fördjupade ämnessidan hittar du där den större kontexten med arkitektur, exempel, beslutsgrunder och närliggande frågor.
Plattform
Windows 11 ARM64
ARM64 påverkar fler applikationer tidigare än man tror. Denna FAQ besvarar de typiska frågorna kring beroenden, tester, installatörer och den ekonomiska bedömningen av ny målplattformshårdvara.
ARM64 är inte längre ett exotiskt sidospår utan en verklig målplattform. Den som beaktar den tidigt undviker senare tekniska återvändsgränder i distribution och vid native‑beroenden.
Varför bör Windows 11 ARM64 beaktas redan idag?
För att nya hårdvaruklasser och mobila arbetsplatser i allt större utsträckning baseras på den, och tekniskt efterarbete senare blir avsevärt dyrare än ett tidigt arkitekturval.
Vad är särskilt kritiskt när det gäller Delphi och native‑beroenden på ARM64?
Framför allt externa bibliotek, databasdrivrutiner, installationsprogram, installationsprocesser och tester på faktisk målplattform måste kontrolleras tidigt.
Behöver en helt egen produkt tas fram för ARM64?
Inte nödvändigtvis. Ofta räcker det att build- och deployment-flöden förbereds noggrant och att kritiska nativeberoenden entkopplas i god tid.
Läs vidare om ämnet i detalj
Om du vill gå från denna FAQ till den mer fördjupade facksidan finner du där helheten kring arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Ska en FAQ bli ett konkret projektsamtal?
Då är nästa rimliga steg inte ytterligare en samling slagord, utan en strukturerad kartläggning av ert bestånd: Vilken affärslogik finns, var bromsar den nuvarande arkitekturen, vilka gränssnitt är kritiska och vilken utbyggnadsväg är tekniskt verkligen bärkraftig?
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 bedömer befintliga system, dataflöden, gränssnitt och målplattformar inte isolerat, utan i samband med domänlogik, drift och framtida 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 driftmässigt hållbar.