Oversikt
FAQ i oversikt
FAQ-landingside
Sentrale spørsmål og svar om prosjektoppstart, leveranser, virksomhetsprogramvare, Delphi, arkitektur, portaler, tjenester og modernisering.
Denne siden samler de vanligste spørsmålene fra startsiden vår, oversiktssidene og de faglige undersidene på ett sted. De kompakte FAQ-ene blir bevisst beholdt på de respektive detaljsidene. Her strukturerer vi dem i tillegg som en landingside, slik at interesserte raskt kan se hvilke temaer vi faktisk behersker innen prosjektoppstart, leveranser, Delphi, C#, Layer-3, portaler, modernisering, datatilgang og plattformstrategi.
Du kan enten hoppe direkte til en temablokk, eller nederst gå videre til den utdypende undersiden. Dermed forblir siden brukbar både som en rask inngang og som en strukturert FAQ-hub.
Prosjektoppstart
Prosjektoppstart, arkitektur & samarbeid
Spørsmål om en fornuftig start, om kartlegging av eksisterende løsning og om tidlige arkitekturbeslutninger.
Direkte til svarene
Leveranser
Leveranser i oversikt
Spørsmål om overtakelse av eksisterende systemer, modernisering, tjenester, datatilgang og langsiktig oppfølging.
Direkte til svarene
Teknologier
Teknologi og arkitektur i oversikt
Spørsmål om Delphi, C#, Layer-3, plattformvalg og den tekniske linjen på tvers av flere utbyggingstrinn.
Direkte til svarene
Prosjekter
Prosjektbilder og referansemønstre
Spørsmål om prosjektstørrelse, driftsansvar, hosting, produktlogikk og systemer som bærer over lengre tid.
Direkte til svarene
Virksomhetsprogramvare
Skreddersydd virksomhetsprogramvare & Layer-3
Spørsmål om lønnsomhet, prosesslogikk, roller, data og langsiktig utvidbarhet.
Direkte til svarene
Ytelse
Multiplattform med Delphi
Spørsmål om Windows, macOS, Linux samt senere iOS- og Android-løp fra felles faglogikk.
Direkte til svarene
Ytelse
Tjenester, REST-server & portaler
Spørsmål om portaler, API-er, Windows- og Linux-tjenester som del av den samme fagarkitekturen.
Direkte til svarene
Integrasjon
Grensesnitt, datastrømmer & plattformmål
Spørsmål om regnskap, API-er, database-ombygging, mapping, overvåking og nye målplattformer.
Direkte til svarene
Delphi
Delphi for virksomhetsapplikasjoner
Hvorfor Delphi fortsatt kan være sterkt ved utviklet forretningslogikk, rapporter og produktive desktop-prosesser.
Direkte til svarene
C#
C# for tjenester & portaler
Spørsmål om REST, integrasjoner, portaler, backend-tjenester og stabil drift.
Direkte til svarene
Arkitektur
Layer-3-arkitektur
Spørsmål om separasjon av UI, forretningslogikk og datatilgang, og hvorfor det er direkte økonomisk relevant.
Direkte til svarene
Delphi-team
Delphi-utviklere fra Freiburg
Spørsmål om ekstern støtte, overtakelse av eksisterende løsninger og teknisk ansvar i etablerte Delphi-systemer.
Rett til svarene
Forvaltning
Delphi-vedlikehold & forvaltning
Spørsmål om stabilisering, videreutvikling, releasesikkerhet og reduksjon av nøkkelpersonavhengighet.
Rett til svarene
Modernisering
Delphi-modernisering
Spørsmål om ombyggingsløp, risiko, bevaring av faglogikk og trinnvis fornyelse i løpende drift.
Rett til svarene
Datatilgang
BDE-utfasing
Spørsmål om FireDAC, native drivere, SQL-særtrekk, deployment og omstrukturering av databasen.
Rett til svarene
PostgreSQL
Delphi, PostgreSQL & FireDAC
Spørsmål om PostgreSQL-migrering, native drivere, SQL-atferd og en rolig omlegging av datatilgang.
Rett til svarene
Delphi REST
Delphi REST-API & REST-server
Spørsmål om REST med Delphi, API-tilsnitt, felles faglogikk og ryddig serverarkitektur.
Rett til svarene
Tjenester
Windows- & Linux-tjenester
Spørsmål om bakgrunnstjenester, tidsstyring, overvåking, restart-atferd og et ryddig driftsoppsett.
Rett til svarene
Teknologi
Delphi multiplattform
Spørsmål om felles kodebase for Windows, macOS og Linux med kontrollerte plattformgrenser.
Rett til svarene
Serverarkitektur
REST-server & tjenester
Spørsmål om API-er, Windows- og Linux-tjenester, serverlogikk, overvåking og driftsansvar.
Rett til svarene
Plattform
Windows 11 ARM64
Spørsmål om ny maskinvare, native avhengigheter, drivere, builds og utrullingsløp.
Rett til svarene
Prosjektstart
Prosjektstart, arkitektur & samarbeid
Mange innledende spørsmål handler ikke om én enkelt teknologi, men om riktig startpunkt: Hva bør man avklare først, hvordan skapes teknisk retning, og hvordan blir en idé til en robust inngang til et reelt prosjekt?
På startsiden dukker det som regel opp de første orienteringsspørsmålene: Hvordan starter man et tiltak på en fornuftig måte, hvilke arkitekturspørsmål bør man avklare tidlig, og når lønner modernisering seg framfor hektisk nyutvikling?
Når lønner Delphi-modernisering seg framfor full nyutvikling?
Når faglogikk, prosesser og datamodell er verdifulle, er en kontrollert ombygging ofte mer økonomisk enn en ny start med funksjonstap og høy innføringsrisiko.
Kan den samme faglogikken kjøre for Windows, macOS og Linux?
Ja. Særlig i Delphi-prosjekter planlegger vi felles forretningslogikk og skiller brukerflate, tjenester og datatilgang slik at flere plattformer kan betjenes ryddig.
Bygger Net-Base også REST-servere og bakgrunnstjenester?
Ja. Windows- og Linux-tjenester, REST-API-er, integrasjonslag og deployment hører for oss til arkitekturen og blir ikke først bygget på i etterkant.
Hvordan starter et typisk prosjekt?
Som regel med en strukturert kartlegging av dagens situasjon: mål, eksisterende systemer, database, plattformer, grensesnitt og driftsrisiko. Ut fra dette oppstår et realistisk startpunkt som kan avgrenses.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer inngående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Tjenester
Tjenester i oversikt
På tjenestesiden oppstår som regel de bredeste oppfølgingsspørsmålene: Hva tar vi konkret ansvar for, hvor langt strekker vårt tekniske ansvar seg, og hvordan henger modernisering, integrasjoner, drift og videreutvikling sammen?
Særlig i etablerte applikasjoner dukker ofte de samme faglige og tekniske spørsmålene opp. Disse punktene avklarer vi tidlig, før et tiltak blir et diffust storskala prosjekt.
Overtar dere også eksisterende Delphi-systemer?
Ja. Vi går regelmessig inn i etablerte Delphi-applikasjoner, analyserer eksisterende løsning, datatilgang, arkitektur og spesialtilfeller og bygger kontrollert videre på det.
Kan REST-servere, portaler og desktop-klienter oppstå fra ett og samme tiltak?
Ja. Nettopp for bedriftsapplikasjoner planlegger vi disse byggesteinene bevisst sammen, slik at den samme forretningslogikken ikke splittes opp i flere særskilte løsninger.
Er en BDE-utfasing også mulig uten full utskifting?
I mange tilfeller ja. Vi løser datatilgang, SQL og deployment trinnvis ut av den gamle strukturen og bygger en native, vedlikeholdbar tilkobling.
Følger dere også opp drift og videreutvikling?
Ja. Release-prosesser, hosting, feilanalyse, databasevedlikehold og senere utvidelser er en del av vårt arbeidsbilde.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Teknologier
Teknologi og arkitektur i oversikt
Denne FAQ-en samler de typiske orienteringsspørsmålene knyttet til teknologivalg: Når er Delphi sterk, når er C# den bedre byggesteinen, og hvordan samler en ryddig arkitektur flere plattformer, tjenester og klienter kontrollert?
Teknologiske beslutninger må passe til teamet, fagområdet og drift. Nettopp derfor avklarer vi ikke disse spørsmålene abstrakt, men alltid på det konkrete systemet.
Når er Delphi fornuftig sammenlignet med en komplett ny plattform?
Alltid når etablert faglogikk, ytelsessterke desktop-prosesser og multiplattform-mål skal videreføres på en økonomisk fornuftig måte, i stedet for å erstatte substans lettvint.
Når bruker dere i tillegg C#?
Fremfor alt for portaler, web-backends, REST-tjenester, integrasjoner og serviceorienterte arkitekturkomponenter som lar seg koble godt sammen med eksisterende desktop-systemer.
Hvor viktig er Layer-3 i praksis?
Svært viktig. Først den ryddige separasjonen av UI, forretningslogikk og datatilgang gjør modernisering, tester, tjenester og fremtidige plattformbytter håndterbare.
Tar dere med nye plattformer som Windows 11 ARM64 tidlig?
Ja. Ny målmaskinvare og deployment-løp blir vurdert tidlig, slik at det ikke senere blir kostbare særprosjekter.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Prosjekter
Prosjektbilder og referansemønstre
Den som ser på prosjektsiden, vil som regel forstå hvilken type tiltak vi faktisk kan bære: engangsverktøy eller mer langlivede systemer med drift, rettighetskonsept, versjoner, integrasjoner og reell videreutvikling.
Mange tiltak høres i starten ulike ut, men har likevel felles mønstre: etablert faglogikk, integrasjoner, rettigheter, versjoner, driftsmessige spørsmål og langsiktig utvidbarhet.
Jobber dere heller med engangs enkelverktøy eller med systemer som bærer over tid?
Tyngdepunktet ligger på systemer med levetid, ansvar og videreutvikling: virksomhetsapplikasjoner, plattformer, tjenester, portaler og produktlogikk.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Særlig for systemer som har vokst over lengre tid, planlegger vi ofte en trinnvis videreutvikling, slik at drift og modernisering passer sammen.
Er hosting og teknisk drift en del av arbeidet deres?
Ja. Release, hosting, overvåking og driftsansvar inngår i vår prosjektplanlegging, slik at den ferdige løsningen ikke bare blir utviklet, men også kan driftes bærekraftig.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Bedriftsprogramvare
Skreddersydd bedriftsprogramvare & Layer-3
Disse spørsmålene dukker typisk opp når standardprogramvare faglig ikke lenger strekker til, og en virksomhet vil vite om et skreddersydd system faktisk kan bygges økonomisk, vedlikeholdbart og utvidbart.
Særlig med skreddersydd bedriftsprogramvare handler det ikke bare om enkeltvise skjermbilder, men om roller, data, kontrollspor og en arkitektur som også senere forblir fleksibel.
Er skreddersydd bedriftsprogramvare bare fornuftig for svært store virksomheter?
Nei. Den lønner seg alltid når standardprogramvare bare kan modellere prosesser via omveier, mediebrudd eller kostbare særregler, og den egentlige verdien ligger i ryddig faglogikk.
Hvorfor vektlegger dere Layer-3 så sterkt i bedriftsapplikasjoner?
Fordi det først er separasjonen av UI, forretningslogikk og datatilgang som sørger for at rapportering, nye klienter, tjenester og framtidige utvidelser forblir økonomisk kontrollerbare.
Kan dere også gå inn i etablerte eksisterende prosesser?
Ja. Nettopp da blir arbeidet vårt sterkt, fordi vi først gjør fagprosesser, eksisterende data og gammel logikk lesbare, og derfra utvikler en bærekraftig målarkitektur.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Se skreddersydd bedriftsprogramvare & Layer-3-applikasjoner i detalj
Ytelse
Multiplattform med Delphi
Virksomheter spør på dette punktet som regel ikke bare etter en teknisk mulighet, men etter en robust strategi: Hvilke deler forblir felles, hva må håndteres plattformspesifikt, og hvordan unngår man at dette blir et dyrt parallellbygg?
Multiplattform blir først verdifullt når den samme faglogikken forblir kontrollert samlet på tvers av flere målsystemer, og plattformspesielle forhold synliggjøres tidlig.
Kan man med Delphi i tillegg til Windows også ta høyde for macOS, Linux, iOS og Android?
Ja. Avhengig av prosjektmålet planlegger vi desktop-mål, mobile grensesnitt og servernære komponenter ut fra en felles faglig linje, i stedet for å bygge hver plattform faglig på nytt.
Hvordan unngår dere at multiplattform-prosjekter løper fra hverandre faglig?
Gjennom en felles kode- og arkitekturstrategi: Fagregler, datamodell og prosesser forblir sentrale, mens plattformspesifikke forskjeller bevisst kapsles inn.
Er også mobile utbyggingstrinn senere fortsatt mulig?
Ja. Når arkitektur, tjenester og grensesnitt er ryddig forberedt, kan iOS- eller Android-mål kobles på senere med vesentlig bedre kontroll.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Ytelse
Services, REST-servere & portaler
Akkurat her må rettigheter, datastrømmer, logging og faglige regler henge sammen. Derfor behandler vi ikke temaet som et web-påbygg, men som en strukturert videreutbygging av samme applikasjonslinje.
Portaler, REST-API-er og tjenester selger seg bare godt når de faglig ikke står ved siden av kjernesystemet, men på en ryddig måte viderefører den samme data- og rollelogikken.
Utvikler dere både REST-servere og Windows- og Linux-tjenester?
Ja. Bakgrunnstjenester, API-er, importer, exporter, portaler og teknisk driftslogikk hører til våre gjentakende oppgavetyper.
Når trenger en bedriftsapplikasjon i tillegg en portal?
Når kunder, partnere eller interne roller skal ha kontrollert tilgang til de samme prosessene, uten at man dupliserer faglige regler i separate grensesnitt.
Hvordan holder dere rettigheter, logging og prosesser konsistente mellom klient og server?
Ved at vi ikke gjemmer fagregler i enkelte endepunkter eller UI-er, men etablerer en tydelig faglig kjerne som klient, portal og service kan bruke sammen.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Integrasjon
Grensesnitt, datastrømmer & plattformmål
Disse spørsmålene kommer som regel når datakvalitet, sporbarhet og fremtidige plattformbytter blir viktigere enn ren dataoverføring fra A til B.
Grensesnitt virker ofte som sidetemaer. I virkeligheten avgjør de datakvalitet, sporbarhet, plattformbytte og stabil drift.
Kan eksisterende grensesnitt og datastrømmer fornyes uten Big Bang?
Ja. I mange prosjekter strukturerer vi mapping, databasebaner, jobber og integrasjoner trinnvis på nytt, slik at reelle prosesser kan fortsette å gå.
Tar dere også på dere integrasjoner mot finansbokføring og tredjepartssystemer?
Ja. Særlig Fibu, API-er, CRM, lager, lisenslogikk eller bransjespesifikke tredjepartssystemer må kobles til på en ryddig måte, dokumenteres, være observerbare og faglig kontrollerbare.
Tenkes plattformmål som Windows 11 ARM64 med i slike integrasjonsprosjekter fra start?
Ja. Nye målplattformer, native avhengigheter og fremtidige deployeringsveier hører tidlig inn i samme planlegging som grensesnitt- og datastrømlogikk.
Les temaet i detalj
Hvis du vil bytte fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Delphi
Delphi for forretningsapplikasjoner
Her handler det om det grunnleggende spørsmålet når Delphi også i dag fortsatt er et bevisst arkitekturvalg, og når andre byggesteiner bør utfylle eller overta på en fornuftig måte.
Med Delphi handler det i virksomheter sjelden om nostalgi, men om spørsmålet hvordan etablert faglogikk, desktop-prosesser og flere målplattformer kan videreføres økonomisk og ryddig.
Hvorfor satser dere fortsatt bevisst på Delphi i dag?
Fordi Delphi i mange forretningsapplikasjoner gir en sterk kombinasjon av etablert forretningslogikk, høytytende desktop-prosesser, database-nærhet og kontrollerbar videreutvikling.
Er Delphi bare interessant for modernisering av eksisterende løsninger?
Nei. Delphi er også fornuftig for nye forretningsapplikasjoner når produktive desktop-arbeidsflyter, rapporter, lokal integrasjon og et felles faglig grunnlag for flere plattformer er viktig.
Hvor ligger grensene for Delphi?
Først og fremst der et initiativ primært er portal-, tjeneste- eller skysentrert. Da kombinerer vi Delphi bevisst med C#, REST-servere eller web-byggesteiner, i stedet for å tvinge alt inn i ett verktøy.
Les temaet i detalj
Hvis du vil bytte fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
C#
C# for tjenester og portaler
Denne FAQ-en retter seg mot virksomheter som ikke ser C# som et mål i seg selv, men vil forstå det som en sterk byggestein for portaler, API-er, integrasjoner og serviceorienterte arkitekturkomponenter.
C# er for oss særlig sterkt når web-portaler, API-er, tjenester, integrasjoner og et rolig driftsoppsett står i fokus.
Når er C# et bedre valg enn Delphi?
Først og fremst når et prosjekt primært består av REST-API-er, portaler, backend-tjenester, integrasjoner eller skynære driftsmodeller.
Bruker dere C# også sammen med eksisterende Delphi-systemer?
Ja. Nettopp denne kombinasjonen er ofte fornuftig: Delphi bærer produktiv faglogikk i klienten, mens C# utfyller med tjenester, portaler og API-lag på en ryddig måte.
Hva er typiske risikoer i C#-prosjekter?
Ofte bygges det for raskt teknisk moderne, uten å avklare roller, faglogikk, logging, utrulling og reelle drifts-spørsmål tydelig nok tidlig. Det er nettopp der vi går inn.
Les temaet i detalj
Hvis du vil bytte fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Arkitektur
Layer-3-arkitektur
Layer-3 forklares ofte teoretisk. I praksis avgjør denne strukturen imidlertid svært direkte om nye klienter, tjenester, tester og utvidelser kan kobles på rolig og kontrollert – eller om de divergerer dyrt.
Layer-3 er ikke et lærebokord, men et svært praktisk svar på monolitter som har vokst over tid, motstridende utvidelser og kostbare koblinger i hverdagen.
Hvorfor er Layer-3 så viktig i virksomhetsapplikasjoner?
Fordi det først er den ryddige separasjonen av UI, forretningslogikk og datatilgang som gjør at utvidelser, tester, tjenester og nye plattformer ikke feiler direkte mot monolitten.
Er Layer-3 bare fornuftig for store prosjekter?
Nei. Særlig mellomstore systemer har stor nytte av dette, fordi det gjør det mulig å koble på senere krav langt mer kontrollert.
Hva er den vanligste feilen ved Layer-3?
At man bare tegner lagene formelt, men fortsetter å skjule de faktiske reglene i UI-koden eller direkte i spesielle SQL-stier. Da finnes oppbyggingen bare på slides, ikke i systemet.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og beslektede temaer.
Delphi-team
Delphi-utviklere fra Freiburg
Ved denne forespørselen handler det sjelden bare om en tilgjengelig person. Som regel ligger spørsmålet bak om en partner faktisk kan overta eldre bestand, faglogikk, datatilgang og den tekniske retningen på en robust måte.
I søket etter Delphi-utviklere handler det sjelden bare om ledig kapasitet. Som regel handler det om robust overtakelse av eksisterende løsning, arkitektur, datatilgang og reelt faglig ansvar.
Når er en ekstern Delphi-utvikler fornuftig?
Fremfor alt når domenekunnskap mangler, modernisering har stoppet opp, eller en applikasjon må videreutvikles faglig uten å miste substansen sin.
Kan dere også gå inn i Delphi-applikasjoner som har vokst over tid?
Ja. Nettopp dette er et fokus: Vi analyserer gammel kode, database, deployment, spesialtilfeller og faglige prosesser, og bygger kontrollert videre på det.
Handler det bare om programmering, eller også om teknisk retning?
Det handler uttrykkelig også om retning. God Delphi-utvikling omfatter for oss arkitektur, datatilgang, integrasjoner, REST-tjenester og reell drift.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og beslektede temaer.
Forvaltning
Delphi-vedlikehold & oppfølging
Vedlikehold høres ofte mindre ut enn det er. I praksis handler det om stabile releaser, synlige risikoer, teknisk orden og spørsmålet om hvordan et system som har vokst frem kan videreutvikles rolig igjen.
Vedlikehold er i etablerte Delphi-systemer mer enn feilretting. Det berører releasesikkerhet, datakonsistens, teknisk gjeld og spørsmålet om hvordan nye krav rolig kan passe inn i det eksisterende.
Hva hører til et godt Delphi-vedlikehold?
Feilanalyse, videreutvikling, databasevedlikehold, release-oppfølging, teknisk dokumentasjon og en arkitektur som ikke gjør nye krav dyrere hver gang.
Kan oppfølging starte også uten full ombygging?
Ja. Ofte begynner den med stabilisering, synliggjøring av risikoer og en prioritert liste for tekniske og faglige forbedringer.
Hvordan reduserer dere avhengighet av enkeltkunnskap?
Ved at vi dokumenterer datapath-er, komponenter, build-steg og kritisk forretningslogikk strukturert, og gjør implisitt kunnskap om til etterprøvbar systemlogikk.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Modernisering
Delphi-modernisering
Disse svarene hjelper særlig der en eldre applikasjon faglig fortsatt er sterk, men teknisk har samlet for mange flaskehalser til å kunne bære nye krav på en ryddig måte.
Det kritiske punktet ved modernisering er sjelden bare overflaten. Som regel handler det om forretningslogikk, data, avhengigheter og en migreringsstrategi som fungerer i daglig drift.
Må en gammel Delphi-applikasjon erstattes fullstendig?
Nei. Ofte er en kontrollert ombygging mer fornuftig: fornye datatilgangen, frikoble logikk, supplere med tjenester og modernisere brukergrensesnitt målrettet.
Hvordan unngår man driftsbrudd ved modernisering?
Gjennom tydelige mellomsteg, rene grensesnitt og en migreringssti der gamle og nye deler kan eksistere kontrollert side om side.
Kan eksisterende forretningslogikk senere også flyttes over i tjenester eller portaler?
Ja. Nettopp derfor løser vi business-logikk ut av UI-nær legacy-kode og flytter den inn i en struktur som klienter, tjenester og API-er kan bruke sammen.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Datatilgang
BDE-utfasing
BDE er sjelden bare en gammel driver. Den henger som regel sammen med historisk SQL-logikk, databaseantakelser og deployeringsløp. Nettopp derfor svarer vi på temaet her bevisst litt bredere.
BDE er sjelden bare en enkelt teknisk byggekloss. Den henger sammen med SQL, deployering, drivere, tegnsett og historiske bivirkninger. Derfor behandler vi utskiftingen som et moderniseringssteg og ikke som et komponentbytte.
Er et bytte til FireDAC eller native drivere mulig uten full ombygging?
Ja, ofte i etapper. Det viktige er å kontrollere SQL, datatyper, transaksjoner og særtilfeller grundig, i stedet for bare å erstatte komponenter 1:1.
Hvorfor berører BDE-utskifting nesten alltid også databasestrukturen?
Fordi gamle tabeller, indekser, tegnsett og historisk fremvokste SQL-stier ofte blir synlige, og de bør ryddes opp i samtidig av hensyn til stabilitet og ytelse.
Hva vinner man konkret med native databasetilknytning?
Enklere deployering, bedre vedlikeholdbarhet, kontrollerbare forbindelser og et betydelig bedre grunnlag for tjenester, API-er og fremtidige utvidelser.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
PostgreSQL
Delphi, PostgreSQL & FireDAC
De som bruker PostgreSQL og BDE-Ablösung mit nativer Anbindung, ønsker som regel mer enn bare en ny komponent. Bak ligger ofte spørsmålet om hvordan datatilgang, SQL, deployering og eksisterende logikk kan bringes tilbake i en bærekraftig linje.
Når det gjelder PostgreSQL og BDE-Ablösung mit nativer Anbindung, handler det ikke bare om en ny tilkoblingskomponent. Som oftest ligger det et større steg bak mot mer robust SQL, bedre deployering og kontrollerbar dataforvaltning.
Når er PostgreSQL et godt valg for Delphi?
Alltid når stabilitet, flerbrukerdrift, tydelige SQL-stier, åpen infrastruktur og ren utvidbarhet for desktop, tjenester eller portaler er viktig.
Er FireDAC alltid riktig vei?
FireDAC er ofte en svært god vei, men ikke som et blindt bytte. Avgørende er SQL-oppførsel, datatyper, transaksjoner, feilbaner og den konkrete eksisterende løsningen.
Kan BDE-, Paradox- eller gamle SQL-systemer gå stegvis over til PostgreSQL?
Ja. I mange tilfeller er en kontrollert trinnvis overgang mer økonomisk enn et hardt brudd, så lenge datamodell og faglogikk er tenkt gjennom på en ryddig måte.
Les mer om temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Delphi REST
Delphi REST-API & REST-server
Denne FAQ-en besvarer det typiske prinsipielle spørsmålet om REST med Delphi bare er et teknisk tillegg, eller en seriøs serverstrategi. Det avgjørende er alltid hvor ryddig klient, regler, data og drift holdes samlet.
REST med Delphi blir sterk når API-er ikke står frikoblet ved siden av eksisterende system, men bærer med seg rettigheter, forretningslogikk, datamodell og drift på en ryddig måte.
Kan man bygge produktive REST-API-er med Delphi?
Ja. Særlig når den samme faglogikken allerede lever i Delphi-bestand, er en REST-server med et rent snitt ofte mer økonomisk enn en helt ny parallellverden.
Når lønner en REST-server seg sammenlignet med direkte databaseaksess?
Så snart flere klienter, portaler, tjenester eller integrasjoner skal bruke de samme reglene kontrollert, og direkte SQL-tilgang blir faglig for risikabel.
Hvordan holder dere Delphi-klient og REST konsistente?
Gjennom en arkitektur der forretningsregler ikke forblir skjult i skjemaer, men gjøres felles anvendelige for klient, API og bakgrunnsprosesser.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunner og tilgrensende temaer.
Tjenester
Windows- & Linux-tjenester
For tjenester handler det sjelden bare om en kjørende prosess. Viktigere er logging, observerbarhet, omstart, datakonsistens og det faglige spørsmålet om hvilke deler som hører hjemme i bakgrunnen og hvilke som ikke gjør det.
Bakgrunnstjenester er ofte den usynlige kjernen i et system. De må kjøre rolig, håndtere tilstandsendringer ryddig og passe robust inn i drift med logging, restart og overvåking.
Når trenger en bedriftsapplikasjon i tillegg Windows- eller Linux-tjenester?
Alltid når import, eksport, tidsstyring, synkronisering, lisenslogikk eller integrasjoner ikke skal være bundet til en innlogget desktop.
Kan tjenester og REST komme fra samme arkitektur?
Ja. Nettopp det er ofte fornuftig, fordi forretningslogikk, datamodell og logging da ikke spriker ut i flere tekniske øyer.
Hva er spesielt viktig for produktive tjenester?
Tydelig feilhåndtering, observerbare tilstander, omstartssikkerhet, logging, deployment og en faglig konsistent prosessering i stedet for stille bakgrunnsmagi.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunner og tilgrensende temaer.
Teknologi
Delphi multiplattform
Denne FAQ-en belyser den tekniske siden av multiplattform-strategien: kodebase, pakking, systemnærhet, release-prosesser og spørsmålet om når flere klienter faktisk blir økonomisk.
Multiplattform fungerer bare ryddig når kodebase, datamodell, plattformforskjeller og deployment planlegges bevisst. Det er nettopp der den egentlige prosjektverdien oppstår.
Kan den samme applikasjonen virkelig kjøre på Windows, macOS og Linux?
Ja, hvis grensesnitt, faglogikk, plattformspesifikke forhold og release-prosesser ikke blandes, men struktureres rent.
Hva er den vanligste feilen i multiplattform-prosjekter?
Å tenke for sent på filsystem, utskrift, signering, målplattformer, packaging og UI-forskjeller. Da blir multiplattform raskt dyrt og inkonsistent.
Kan tjenester og API-er bruke den samme faglogikken?
Ja. En god arkitektur sørger for at ikke hver plattform utvikler sin egen faglige særvei.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Serverarkitektur
REST-server & tjenester
Når API-er og tjenester bare høres teknisk moderne ut, men ikke er faglig rent avgrenset, blir de raskt et problem. Denne FAQ-en setter nettopp disse beslutningene i kontekst.
Mange systemer feiler ikke på API-idéen, men på at serverlogikk senere improviseres og hektes på en eksisterende desktop-base. Vi planlegger disse delene bevisst sammen.
Når trenger en bedriftsapplikasjon i tillegg en REST-server?
Så snart flere klienter, portaler, mobile tilganger, eksterne integrasjoner eller frikoblede prosesser kontrollert skal bruke den samme faglogikken.
Støtter dere også Windows- og Linux-tjenester?
Ja. Bakgrunnsprosesser, tidsstyring, synkronisering, eksport, lisenstjenester og tekniske følgeprosesser er blant våre typiske oppgaver.
Hvordan bevares faglig konsistens mellom klient, REST og tjeneste?
Gjennom en arkitektur der business-regler ikke er gjemt i enkeltgrensesnitt, men forblir felles brukbare og etterprøvbare.
Les temaet i detalj
Hvis du vil gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilgrensende temaer.
Plattform
Windows 11 ARM64
ARM64 påvirker mange applikasjoner tidligere enn man tror. Denne FAQ-en besvarer de typiske spørsmålene rundt avhengigheter, tester, installatører og den økonomiske vurderingen av ny målhardware.
ARM64 er ikke lenger et eksotisk sideemne, men en reell målplattform. Den som tar det med tidlig, unngår senere tekniske blindgater i deployment og ved native avhengigheter.
Hvorfor bør Windows 11 ARM64 allerede tas hensyn til i dag?
Fordi nye maskinvareklasser og mobile arbeidsplasser i økende grad satser på det, og teknisk etterarbeid senere blir betydelig dyrere enn en tidlig arkitekturbeslutning.
Hva er spesielt kritisk ved Delphi og native avhengigheter på ARM64?
Særlig eksterne biblioteker, databasedrivere, installasjonsprogrammer, oppsettprosesser og tester på reell målmaskinvare må verifiseres tidlig.
Må det lages et helt eget produkt for ARM64?
Ikke nødvendigvis. Ofte er det tilstrekkelig å forberede build- og deployment-løpene ryddig og frikoble kritiske native avhengigheter i tide.
Les mer om temaet i detalj
Hvis du ønsker å gå fra denne FAQ-en til den mer dyptgående fagsiden, finner du der den større sammenhengen med arkitektur, eksempler, beslutningsgrunnlag og tilstøtende temaer.
Skal en FAQ bli til en konkret prosjektsamtale?
Da er neste fornuftige steg ikke enda en samling av stikkord, men en strukturert vurdering av dagens løsning: Hvilken forretningslogikk finnes, hvor bremser dagens arkitektur, hvilke grensesnitt er kritiske, og hvilken videreutviklingssti er teknisk faktisk bærekraftig?