Frågor och svar
Centrala FAQ – översikt
FAQ landningssida
Centrala frågor och svar om projektstart, tjänster, företagsprogramvara, Delphi, arkitektur, portaler, tjänster och modernisering.
Denna sida samlar de vanligaste frågorna från vår startsida, översiktssidorna och de fackliga undersidorna på ett ställe. FAQ:erna i kompakt form lämnas medvetet kvar 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 temablok eller gå vidare från varje avsnitt till fördjupande undersida nedan. På så sätt fungerar sidan både som snabb ingång och som en strukturerad FAQ-hub.
Projektstart
Projektstart, arkitektur & samarbete
Frågor om en lämplig start, om inventering och om tidiga arkitekturval.
Direkt till svaren
Tjänster
Översikt över tjänster
Frågor om övertagande av befintliga system, modernisering, tjänster, dataåtkomst och långsiktigt stöd.
Direkt till svaren
Teknologier
Teknologi och arkitektur i översikt
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, driftansvar, 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-vägar 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 en 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 förbli stark för 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 ekonomiskt direkt relevant.
Direkt till svaren
Delphi-team
Delphi-utvecklare från Freiburg
Frågor om extern support, övertagande av befintliga lösningar och tekniskt ansvar i etablerade Delphi-system.
Direkt till svaren
Delphi-Team
Delphi-Utvecklare för München
Frågor om extern support, övertagande av befintliga system och tekniskt ansvar i etablerade Delphi-system för företag i München‑området.
Direkt till svaren
Delphi-Team
Delphi-Utvecklare för Berlin
Frågor om extern support, övertagande av befintliga system och tekniskt ansvar i etablerade Delphi-system för företag i Berlin‑området.
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, risker, bevarande av domänlogik och stegvis förnyelse i löpande drift.
Direkt till svaren
Dataåtkomst
BDE-Avveckling
Frågor om FireDAC, native drivrutiner, SQL-särskildheter, utrullning 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å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, tidsstyrning, övervakning, omstartsbeteende och tydlig driftavgränsning.
Direkt till svaren
Teknologi
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, nativa beroenden, drivrutiner, builds och utrullningsvägar.
Direkt till svaren
Projektstart
Projektstart, arkitektur & samarbete
Många inledande frågor handlar inte om en enskild teknik, utan om rätt startpunkt: Vad bör klargöras först, hur skapas teknisk orientering och hur blir en idé en hållbar ingång till ett verkligt projekt?
På startsidan dyker vanligtvis de första orienteringsfrågorna upp: Hur börjar ett projekt på ett rimligt sätt, vilka arkitekturfrågor bör klargöras tidigt och när lönar sig modernisering istället för en hastig nyutveckling?
När är Delphi-modernisering att föredra framför fullständig nyutveckling?
Om affärslogik, processer och datamodell är värdefulla är en kontrollerad ombyggnad ofta mer ekonomisk än en nystart som medför funktionsförlust och hög införanderisk.
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 användargränssnitt, tjänster och dataåtkomst så att flera plattformar kan försörjas på ett ordnat sätt.
Bygger Net-Base också REST-servrar och bakgrundstjänster?
Ja. Windows- och Linux-tjänster, REST-API:er, integrationsskikt och driftsättning tillhör enligt oss 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 driftrisker. Därifrån uppstår en realistiskt anpassningsbar startpunkt.
Fördjupning i ämnet
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där ett större sammanhang med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Tjänster
Tjänster i översikt
På tjänstesidan uppstår vanligtvis de mest omfattande frågorna: Vad ansvarar vi konkret för, hur långt sträcker sig vårt tekniska ansvar och hur samspelar modernisering, integrationer, drift och vidareutveckling?
Särskilt för växande applikationer uppstår ofta samma domänspecifika och tekniska frågor. Dessa punkter klargör vi tidigt, innan ett uppdrag blir ett diffust storprojekt.
Tar ni även över befintliga Delphi-system?
Ja. Vi går regelbundet in i befintliga Delphi-applikationer, analyserar bestånd, dataåtkomst, arkitektur och specialfall och bygger vidare kontrollerat utifrån det.
Kan REST-servrar, portaler och desktopklienter uppstå ur ett uppdrag?
Ja. Just för företagsapplikationer planerar vi dessa byggstenar medvetet tillsammans, så att samma affärslogik inte splittras över flera speciallösningar.
Är en BDE-ersättning möjlig utan fullständig utbyte?
I många fall ja. Vi lyfter successivt ut dataåtkomst, SQL och deployment från den gamla strukturen och bygger en native, underhållbar anslutning.
Följer ni även drift och vidareutveckling?
Ja. Releaseprocesser, hosting, felanalys, databasunderhåll och senare utbyggnader ingår i vårt ansvarsområde.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där det större sammanhanget kring arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Teknologi
Teknologi och arkitektur i översikt
Denna FAQ sammanför typiska orienteringsfrågor vid teknikval: När är Delphi starkt, när är C# den bättre byggstenen och hur leder en ren arkitektur flera plattformar, tjänster och klienter samman på ett kontrollerat sätt?
Tekniska beslut måste passa teamet, verksamheten och driften. Just därför tar vi inte upp dessa frågor abstrakt, utan alltid utifrån det konkreta systemet.
När är Delphi lämpligt jämfört med en komplett nyplattform?
Alltid när etablerad domänlogik, högpresterande desktopprocesser och mål för flera plattformar är ekonomiskt bättre att föra vidare än att vårdslöst ersätta systemets kärna.
När använder ni dessutom C#?
Främst för portaler, webb-backends, REST-tjänster, integrationer och serviceorienterade arkitekturkomponenter som kan integreras väl med befintliga desktop-system.
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.
Tar ni tidigt hänsyn till nya plattformar som Windows 11 ARM64?
Ja. Ny mål-hårdvara och deployment‑vägar granskas tidigt för att undvika kostsamma specialprojekt senare.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där det större sammanhanget kring arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Projekt
Projektbilder och referensmönster
Den som tittar på projektsidan vill oftast förstå vilken typ av projekt vi faktiskt bär: engångsverktyg eller mer 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 körning, ansvar och vidareutveckling: företagsapplikationer, plattformar, tjänster, portaler och produktlogik.
Kan befintliga produkter eller interna system moderniseras parallellt?
Ja. Särskilt för mer långsamt växande system planerar vi ofta en stegvis vidareutveckling så att drift och modernisering passar ihop.
Ingår hosting och teknisk drift i ert arbete?
Ja. Release, hosting, övervakning och driftsansvar integreras i vår projektplanering så att den färdiga lösningen inte bara utvecklas utan också kan drivas hållbart.
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 kring 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 funktionellt och ett företag vill veta om ett skräddarsytt system verkligen kan byggas kostnadseffektivt, underhållsbart och utbyggbart.
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 rörlig även senare.
Är individuell företagsprogramvara bara lämplig för mycket stora företag?
Nej. Den är berättigad när standardprogramvara bara kan avbilda processer med omvägar, mediebrott eller dyra specialregler, och det egentliga värdet ligger i ren domänlogik.
Varför betonar ni Layer-3 så starkt i företagsapplikationer?
Först separationen av UI, affärslogik och dataåtkomst säkerställer att rapportering, nya klienter, tjänster och framtida utvidgningar förblir ekonomiskt hanterbara.
Kan ni också ta er an etablerade befintliga processer?
Ja. Särskilt då blir vårt arbete starkt, eftersom vi först gör domänprocesser, befintliga data och gammal logik läsbara och därifrån utvecklar en hållbar målarkitektur.
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 kring 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 hållbar strategi: Vilka delar förblir gemensamma, vad måste hanteras plattformsspecifikt och hur undviker man dyr parallellutveckling?
Multiplattform blir först värdefullt när samma domänlogik hålls kontrollerat gemensam över flera målplattformar och plattformspecifika särdrag synliggörs tidigt.
Går det med Delphi—utöver Windows—även att räkna in 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 funktionell linje, istället för att bygga varje plattform om funktionellt.
Hur undviker ni att multiplattformsprojekt glider isär funktionellt?
Genom en gemensam kod- och arkitekturstrategi: affärsregler, datamodell och processer förblir centrala, medan plattformsspecifika skillnader avsiktligt kapslas in.
Är även mobila utbyggnadsnivåer möjliga i efterhand?
Ja. Om arkitektur, tjänster och gränssnitt är ordentligt förberedda kan iOS- eller Android-mål anslutas senare på ett betydligt mer kontrollerat sätt.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Leistung
Tjänster, REST-servrar & portaler
Just här måste rättigheter, dataflöden, loggning och funktionella regler hållas tillsammans. Därför behandlar vi ämnet inte som en webb-påbyggnad, utan som en ordnad utbyggnad av samma applikationslinje.
Portaler, REST-API:er och tjänster fungerar endast väl om de inte står vid sidan av kärnsystemet, utan för vidare samma data- och rolllogik på ett konsekvent sätt.
Utvecklar ni både REST-servrar samt Windows- och Linux-tjänster?
Ja. Bakgrundstjänster, API:er, importer, exporter, portaler och teknisk driftslogik hör till våra återkommande uppgifter.
När behöver en företagsapplikation dessutom en portal?
När kunder, partner eller interna roller ska ha kontrollerad åtkomst till samma processer utan att man duplicerar funktionella regler i separata gränssnitt.
Hur hålls rättigheter, loggning och processer konsistenta mellan klient och server?
Genom att vi inte gömmer domänregler i enskilda endpunkter eller UI:er, utan skapar en tydlig domänlogik som klient, portal och tjänst kan använda gemensamt.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade ämnessidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och angränsande ämnen.
Integration
Gränssnitt, dataflöden & plattformsmål
Dessa frågor uppstår vanligtvis 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 bisaker. I verkligheten avgör de datakvalitet, spårbarhet, plattformsbyte 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 verkliga processer kan fortsätta att köras.
Tar ni även över integrationer till finansbokföring och tredjepartssystem?
Ja. Särskilt finansbokföring, API:er, CRM, lager, licenslogik eller branschspecifika tredjepartssystem måste anslutas med tydlig dokumentation, vara observerbara och domänmässigt kontrollerbara.
Beaktar ni plattformsmå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 hör tidigt in 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 fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutskriterier och närliggande ämnen.
Delphi
Delphi för företagsapplikationer
Här handlar det om huvudfrågan när Delphi fortfarande idag är ett medvetet arkitekturval och när andra komponenter bör komplettera eller ta över på ett meningsfullt sätt.
När det gäller Delphi handlar det i företag sällan om nostalgi, utan om frågan hur etablerad domänlogik, desktop‑processer och flera målplattformar kan fortsätta drivas vidare på ett ekonomiskt hållbart och tekniskt konsekvent 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 desktop‑processer, databasnära funktioner och kontrollerbar vidareutveckling.
Är Delphi bara relevant för modernisering av befintliga system?
Nej. Delphi är även 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 gränserna för Delphi?
Särskilt 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 enda verktyg.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutskriterier och närliggande ämnen.
C#
C# för tjänster & portaler
Denna FAQ vänder 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 särskilt starkt när webbportaler, API:er, tjänster, integrationer och en lugn driftsprofil står i fokus.
När är C# jämfört med Delphi det bättre valet?
Särskilt när ett projekt primärt består av REST‑API:er, portaler, backendtjänster, integrationer eller cloudnära driftsmodeller.
Använder ni C# också tillsammans med befintliga Delphi‑system?
Ja. Precis denna kombination är ofta lämplig: Delphi bär produktiv affärslogik i klienten, medan C# kompletterar tjänster, portaler och API-lager på ett renodlat sätt.
Vilka är typiska risker vid C#-projekt?
Ofta byggs tekniskt modernt för snabbt, utan att roller, affärslogik, loggning, deployment och verkliga driftsfrågor tidigt nog renodlas. Det är exakt där vi går in.
Läs mer om ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder 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 utbyggnader kan ansluta utan problem eller kostsamt glida isär.
Layer-3 är inte ett läroboksbegrepp, utan ett mycket praktiskt svar på växande monoliter, motstridiga tillägg och kostsamma kopplingar i det dagliga arbetet.
Varför är Layer-3 så viktigt för företagsapplikationer?
Först när UI, affärslogik och dataåtkomst är tydligt separerade säkerställs att utbyggnader, tester, tjänster och nya plattformar inte misslyckas direkt mot monoliten.
Är Layer-3 bara lämpligt för stora projekt?
Nej. Särskilt medelstora system drar stor nytta av det, eftersom senare krav då kan anslutas betydligt mer kontrollerat.
Vad är det vanligaste misstaget med Layer-3?
Att man bara ritar upp lager formellt, medan de faktiska reglerna istället ligger kvar i UI-koden eller direkt i särskilda SQL-vägar. Då finns uppbyggnaden bara i presentationer, inte i systemet.
Läs mer om ämnet i detalj
Om du från denna FAQ vill gå vidare till den mer fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Delphi-Team
Delphi-utvecklare från Freiburg
Vid en sådan förfrågan handlar det sällan bara om en tillgänglig person. Ofta ligger frågan bakom om en partner verkligen kan ta över det befintliga beståndet, affärslogiken, dataåtkomsten och den tekniska riktningen på ett robust sätt.
När man söker efter Delphi-utvecklare handlar det sällan bara om ledig kapacitet. Oftast handlar det om en robust övertagande av bestånd, arkitektur, dataåtkomst och verkligt funktionellt ansvar.
När är en extern Delphi-utvecklare lämplig?
Framför allt när kunskap om befintligt bestånd saknas, moderniseringsarbetet har stannat upp eller en applikation måste vidareutvecklas funktionellt utan att förlora sin substans.
Kan ni också ta er an befintliga Delphi-applikationer?
Ja. Precis det är ett fokusområde: Vi analyserar äldre kodbas, databas, deployment, specialfall och affärsprocesser och bygger vidare kontrollerat på det.
Handlar det bara om programmering eller också om teknisk inriktning?
Det handlar uttryckligen även om riktning. God Delphi-utveckling omfattar för oss arkitektur, dataåtkomst, integrationer, REST-tjänster och den verkliga driften.
Läs ä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.
Delphi-team
Delphi-utvecklare för München
Vid denna typ av förfrågan handlar det sällan bara om en tillgänglig person. Oftast gäller det frågan om en partner verkligen kan övertaga befintlig kodbas, domänlogik, dataåtkomst och den tekniska riktningen på ett tillförlitligt sätt.
Vid förfrågningar från München handlar det sällan bara om ledig kapacitet. Ofta gäller det en tillförlitlig övertagning av befintligt bestånd, arkitektur, dataåtkomst och verkligt tekniskt ansvar i krävande företagsmiljöer.
När är en extern Delphi-utvecklare för München lämplig?
Främst när kunskap om beståndet saknas, moderniseringen har stannat upp eller en applikation behöver vidareutvecklas funktionellt utan att förlora sin substans.
Arbetar ni också för företag i München-området utan lokalt team?
Ja. Det är precis ett av våra fokusområden: Vi analyserar äldre kod, databas, deployment, specialfall och verksamhetsflöden och bygger kontrollerat vidare utifrån det, även när produktansvar, drift och vidareutveckling är fördelade på flera roller.
Handlar det bara om programmering eller även om teknisk riktning?
Det handlar uttryckligen även om riktning. God Delphi-utveckling omfattar för oss arkitektur, dataåtkomst, integrationer, REST-tjänster och den verkliga driften.
Läs ä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.
Delphi-team
Delphi-utvecklare för Berlin
Vid denna typ av förfrågan handlar det sällan bara om en tillgänglig person. Oftast gäller det frågan om en partner verkligen kan övertaga befintlig kodbas, domänlogik, dataåtkomst och den tekniska riktningen på ett tillförlitligt sätt.
Vid förfrågningar från Berlin handlar det sällan bara om ledig kapacitet. Ofta handlar det om en tillförlitlig övertagning av bestånd, arkitektur, dataåtkomst och verkligt tekniskt ansvar i snabbt föränderliga produkt- och plattformslandskap.
När är en extern Delphi-utvecklare för Berlin lämplig?
Framför allt när beståndskunskap saknas, ett produkt- eller internt system behöver vidareutvecklas snabbare, eller när moderna API:er, portaler och tjänster ska anslutas till befintlig Delphi-logik.
Kan ni också ta över hybrida landskap bestående av Delphi, tjänster och webbdelar?
Ja. Vi ordnar äldre kod, databas, gränssnitt, bakgrundsprocesser och nya plattformsdelar i en gemensam teknisk linje, istället för att bara hantera enskilda ärenden.
Rör det sig enbart om programmering eller även om teknisk inriktning?
Det handlar uttryckligen också om inriktning. God Delphi-utveckling omfattar för oss arkitektur, dataåtkomst, integrationer, REST-tjänster och den verkliga driften.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där helheten kring arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Support
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 befintligt system åter kan vidareutvecklas i kontrollerad form.
Underhåll är i väletablerade Delphi-system mer än buggfixning. Det rör releassäkerhet, datakonsistens, teknisk skuld och hur nya krav kan införas utan att störa befintlig kodbas.
Vad ingår i ett gott Delphi-underhåll?
Felanalys, vidareutveckling, databasunderhåll, releassupport, teknisk dokumentation och en arkitektur som inte automatiskt gör nya krav dyrare.
Kan support starta även utan fullständig ombyggnad?
Ja. Ofta börjar den 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 datavägar, komponenter, build-steg och kritisk domänlogik, och gör implicit kunskap till spårbar systemlogik.
Läs mer om ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där helheten kring arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Modernisering
Delphi-modernisering
Dessa svar är särskilt användbara där en äldre applikation fortfarande är stark funktionellt, men tekniskt har samlat för många flaskhalsar för att bära nya krav på ett rent sätt.
Den avgörande punkten vid modernisering är sällan bara gränssnittet. Vanligtvis handlar det om domänlogik, data, beroenden och en migrationsstrategi som fungerar i daglig drift.
Måste en gammal Delphi-applikation helt ersättas?
Nej. Ofta är en kontrollerad ombyggnad mer rimlig: förnya dataåtkomst, koppla loss logik, komplettera med tjänster och modernisera gränssnitt målmedvetet.
Hur undviker man driftavbrott 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 också övergå till tjänster eller portaler?
Ja. Precis därför extraherar vi affärslogik från UI-nära gammalkod och placerar den i en struktur som klienter, tjänster och API:er kan använda gemensamt.
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 kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Dataåtkomst
BDE-ersättning
BDE är sällan bara en gammal drivrutin. Den hänger oftast ihop med historisk SQL-logik, databasantaganden och deployment‑vä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 följdeffekter. Därför ser vi ersättningen som ett moderniseringssteg och inte som ett rent komponentbyte.
Är en övergång till FireDAC eller native-drivrutiner möjlig 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?
Därför att gamla tabeller, index, teckenuppsättningar och historiskt uppbyggda SQL‑vägar ofta blir synliga, vilka bör åtgärdas för stabilitet och prestanda.
Vad vinner man konkret med en native databasanslutning?
Enklare deployment, bättre underhållbarhet, kontrollerbara anslutningar och en klart bättre grund för tjänster, API:er och framtida utbyggnader.
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 kontexten med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den som använder PostgreSQL och BDE-Ablosung mit nativer Anbindung vill oftast mer än bara en ny komponent. Ofta handlar det om hur dataåtkomst, SQL, deployment och befintlig logik återförs till en hållbar linje.
Med PostgreSQL och FireDAC handlar det inte bara om en ny anslutningskomponent. Vanligtvis innebär det ett större steg mot mer robust SQL, bättre deployment och kontrollerbar datahantering.
När är PostgreSQL ett bra val för Delphi?
När stabilitet, fleranvändardrift, tydliga SQL‑vägar, ö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‑beteenden, 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 mer ekonomisk än ett hårt avbrott, så länge datamodell och domänlogik beaktas ordentligt.
Läs ämnet i detalj
Om ni från denna FAQ vill byta till den fördjupade ämnessidan hittar ni 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 är enbart ett tekniskt tillägg eller en seriös serverstrategi. Avgörande är alltid hur väl klient, regler, data och drift hålls samman.
REST med Delphi blir kraftfullt när API:er inte står lösgjorda bredvid det befintliga beståndet, utan konsekvent bär behörigheter, affärslogik, datamodell och drift.
Kan man bygga produktiva REST-API:er med Delphi?
Ja. Särskilt om samma affärslogik redan finns i Delphi-beståndet är en väl avgränsad REST-server ofta mer kostnadseffektiv än en helt ny parallellvä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 domänperspektiv.
Hur håller ni Delphi-klient och REST konsekventa?
Genom en arkitektur där affärsregler inte göms i formulär utan görs gemensamt åtkomliga för klient, API och bakgrundsprocesser.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill byta till den fördjupade ämnessidan hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ä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 sakliga frågan vilka delar hör hemma i bakgrunden och vilka inte.
Bakgrundstjänster är ofta systemets osynliga kärna. De måste köras stabilt, hantera tillståndsövergångar tydligt och med loggning, omstart och övervakning passa robust in i driften.
När behöver en företagsapplikation dessutom Windows- eller Linux-tjänster?
När importer, exporter, tidsstyrning, synkronisering, licenslogik eller integrationer inte bör vara bundna till en inloggad skrivbordsmiljö.
Kan tjänster och REST byggas ur samma arkitektur?
Ja. Det är ofta lämpligt, eftersom affärslogik, datamodell och loggning då inte splittras i flera tekniska öar.
Vad är särskilt viktigt för produktiva tjänster?
Tydlig felhantering, observerbara tillstånd, omstartssäkerhet, loggning, utrullning och en domänmässigt konsekvent bearbetning istället för tyst bakgrundsmagi.
Läs vidare om ämnet i detalj
Om ni från denna FAQ vill byta till den fördjupade ämnessidan hittar ni där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Teknologi
Delphi Multiplattform
Denna FAQ belyser den tekniska sidan av multiplattformsstrategin: kodbas, paketering, systemnära aspekter, release-processer och frågan när flera klienter verkligen blir lönsamma.
Multiplattform fungerar bara om kodbasen, datamodellen, plattformspecifika skillnader och driftsättning planeras medvetet. Precis där uppstår det verkliga projektvärdet.
Kan samma applikation verkligen köras på Windows, macOS och Linux?
Ja. Om användargränssnitt, affärslogik, plattformspecifika särdrag och release-processer inte blandas utan istället struktureras tydligt.
Vad är det vanligaste felet i multiplattformsprojekt?
Att tänka för sent på filsystem, utskrift, signering, målplattformar, paketering och UI-skillnader. Då blir multiplattform snabbt dyrt och inkonsekvent.
Kan tjänster och API:er använda samma affärslogik?
Ja. En bra arkitektur säkerställer att inte varje plattform utvecklar sin egen avvikande affärslogik.
Läs vidare 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.
Serverarkitektur
REST-Server & tjänster
Om API:er och tjänster bara låter tekniskt moderna men inte är funktionellt tydligt avgränsade, blir de snabbt ett problem. Denna FAQ sätter just dessa beslut i sitt sammanhang.
Många system misslyckas inte på grund av själva API-idén, utan därför att serverlogik senare improviserat kopplas till ett befintligt desktopbestånd. Vi planerar dessa delar medvetet tillsammans.
När behöver en företagsapplikation dessutom en REST-server?
När flera klienter, portaler, mobila åtkomster, externa integrationer eller frikopplade processer behöver använda samma affärslogik på ett kontrollerat sätt.
Stöder ni också Windows- och Linux-tjänster?
Ja. Bakgrundsprocesser, schemaläggning, synkronisering, exporter, licenstjänster och tekniska understödjande processer hör till våra typiska uppgifter.
Hur behålls den affärsmässiga konsekvensen mellan klient, REST och tjänst?
Genom en arkitektur där affärsregler inte göms i enskilda gränssnitt utan är gemensamt användbara och spårbara.
Läs vidare 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.
Plattform
Windows 11 ARM64
ARM64 påverkar många applikationer tidigare än väntat. Denna FAQ besvarar typiska frågor om beroenden, tester, installatörer och den ekonomiska bedömningen av ny målmaskinvara.
ARM64 är inte längre ett exotiskt sidospår utan en verklig målplattform. Den som planerar för den tidigt undviker senare tekniska återvändsgränder vid driftsättning och för native beroenden.
Warum sollte Windows 11 ARM64 heute schon beruecksichtigt werden?
För att nya hårdvaruklasser och mobila arbetsplatser i allt högre grad bygger på den, och teknisk efterbearbetning senare blir avsevärt dyrare än ett tidigt arkitekturval.
Was ist bei Delphi und nativen Abhängigkeiten auf ARM64 besonders kritisch?
Framför allt externa bibliotek, databasdrivrutiner, installatörer, installationsprocesser och tester på verklig målmaskinvara måste granskas tidigt.
Muss für ARM64 ein komplett eigenes Produkt entstehen?
Inte nödvändigtvis. Ofta räcker det att förbereda build- och deployment-flöden ordentligt och frikoppla kritiska native beroenden i god tid.
Läs ämnet i detalj
Om du vill gå från denna FAQ till den fördjupade facksidan hittar du där det större sammanhanget med arkitektur, exempel, beslutsgrunder och närliggande ämnen.
Ska en FAQ bli ett konkret projektgespräch?
Då är nästa rimliga steg inte ännu en lista med nyckelord, utan en strukturerad inordning av er befintliga lösning: Vilken verksamhetslogik finns, var bromsar den nuvarande arkitekturen, vilka gränssnitt är kritiska och vilken utbyggnadsväg är tekniskt verkligen hållbar?