Í mörgum fyrirtækjum er Borland Database Engine (BDE) enn hluti af viðskipta- og rekstrarmiðlægum Delphi-lausnum: uppsafnað sérsvið, UI-nánar gagnasamskiptum með TTable/TQuery, að hluta til enn Paradox/dBase og að hluta til eldri Client/Server-uppsetningar. Raunveruleikinn er oft sá: Hugbúnaðurinn keyrir, notendur þekkja ferlana og í daglegum rekstri er engin bráð þörf til að „snerta neitt“. Á sama tíma breytist tæknilegur grunnur: stýrikerfi eru harðgerðari, útgáfusending (deployment) er staðlað, 64‑bita er orðið vænting, og gagnageymsla á að færa sig yfir á gagnagrunnsþjóna með hreinu aðkomu- og afritunarreglugerð.
Það er einmitt hér sem „Borland BDE með BDE-Ablösung mit nativer Anbindung skipta út“ verður að stefnumiðaðri verkefni um nútímavæðingu. BDE-Ablosung mit nativer Anbindung er í núverandi Delphi-útgáfum staðlaður gagnaaðgangur fyrir nútíma gagnagrunna. Hann skilar samræmdu atferli, stöðugum drifurum, Unicode-stuðningi, eftirliti/tracing og arkitektúr sem getur þjónað jafnt skjáborðsviðmótum sem þjónustum og REST-þjónum. Yfirfærsla er þó sjaldan aðeins 1:1 íhlutaskipti – sérstaklega ekki þegar arflausnin hefur í gegnum árin innbyggt BDE-sértækt atferli (forsendur um viðskipti, gagnaformát, síur/röðun, Cached Updates, þriðja aðila skýrslugerðir).
Þessi grein einbeitir sér að hagnýtu framkvæmdinni: Hvernig skiptað er út BDE fyrir FireDAC án þess að ógna sérsviðinu og án þess að þurfa „Big‑Bang“ endurræsingar? Þið fáið framkvæmanlegt módel, tæknileg markmynd og ábendingar um algengar vandasvæði í rekstri fyrirtækja.
Af hverju BDE‑útskipti eru í dag meira en tæknileg viðhald
Svo lengi sem BDE-forrit virkar líta útskipti út eins og einfalt „kóðaþrif“. Í raunveruleikanum spretta þrýstingur hins vegar oftast af rekstrar- og áhættuatriðum.
Deployment, öryggisgrunnlínur og „No‑Touch“ notendur
BDE var sögulega hannað fyrir staðbundna stillingu (BDE Administrator, alias‑skilgreiningar, NetDir, sameiginlegar stillingarskrár). Í nútímalegum umhverfum eru handvirkar aðgerðir og vélabundnar alþjóðlegar uppsetningar illa samrýmanlegar hugbúnaðarútbreiðslu, harðgervingu og endurskoðanleika. FireDAC leyfir mun stjórnlegri útgáfur því tengiparametrar og drifara‑stillingar má halda nálægt forritinu.
64‑Bit, Windows‑nútímavæðing og nýir vettvangar
Síðasta þegar forrit þarf að keyra í 64‑bita umhverfi (minniskröfur, drifara-/Office‑vistkerfi, ný vélbúnaður, Terminal Server‑stefna) verður BDE í reynd hindrun. FireDAC styður samræmilega 32/64‑bita og er því lykileining í þeirri Delphi‑nútímavæðingu sem ekki má láta skaðast af gagnaaðgangi. Auk þess verða þemu eins og Windows 11 ARM64 og hybrid Client/Service‑arkitektúr fyrst raunhæf að skipuleggja.
Gagnastefna: frá skrábundnu að þjónustubundnu
Mörg BDE‑forrit bera enn með sér arfleifð frá Paradox/dBase tímabilinu. Þessar skrábundnu gagnagrunnalausnir eru viðkvæmari í fjölnotendarekstri, erfiðari í stjórn og passa illa við nútímakröfur (hlutaréttindi, dulkóðun, eftirlit, hágæðavinnutími). FireDAC er ekki „nýr Paradox‑drifari“, en hann er nútímalegur aðgangur að SQL Server, PostgreSQL, MariaDB og Firebird. Í framkvæmd er BDE‑útskipti oft upphaf að faglegri gagnageymslu og rekstri.
Viðhald og greiningarmöguleikar í rekstri
Vanmetinn kostnaður er villuleit: sporadísk veiklásavandamál, ósamhverft cursor‑atferli, erfitt að rekja parametraumbreytingar eða net-/stefnuvandamál. FireDAC býður með logging, monitoring og skýrara týputafli betri forsendur fyrir endurleitarlegar villugreiningar. Fyrirtæki sem hyggjast reka forrit til langs tíma og viðhalda því staðbundið njóta beins ávinnings.
BDE vs. FireDAC: munur sem skiptir máli í flutningi
Á blaði má para íhluti saman. Í reynslunni snýst það um breytingar á atferli sem geta skapað hliðarverkanir í faglegri hegðun. Stutt yfirlit:
Komponenta‑mappun (sem upphafspunktur)
- TDatabase (BDE) → TFDConnection (FireDAC)
- TQuery (BDE) → TFDQuery
- TTable (BDE) → TFDTable (í nútímavæðingum oft betra: Query-/View‑bundinn aðgangur)
- TStoredProc (BDE) → TFDStoredProc
Algengasta atferlismunina
- Parametrar og gagnatýpur: FireDAC vinnur nákvæmar. „Það mun ganga“ SQL birtist hraðar sem villa (t.d. dagsetningar sem strengir, dulin umbreyting, óljós null‑eigindi).
- Transaktsjónir: Arf‑kóði gerir oft ráð fyrir dulinum commit‑förum (loka dataset, AutoCommit‑snið). Með FireDAC borgar sig meðvituð transaktsjónarstýring því hún eykur faglega samkvæmni.
- Cursor/Fetch: FireDAC hefur önnur default‑gildi og fleiri stillimöguleika. Óhagkvæm mynstur (stór result‑sett fyrir UI‑lista) verða sýnilegri en má markvisst hagræða.
- Unicode: Í nútíma Delphi‑útgáfum er Unicode sjálfgefið. FireDAC‑keðjan (client‑library, connection‑options, DB‑collation, field‑types) þarf að vera samstillt, annars eru hætt við stafa‑ og samanburðarvandamálum.
- Deployment: Fer eftir gagnagrunninum þarf client‑bókasöfn (t.d. libpq fyrir PostgreSQL). Það þarf að skipuleggja snemma til að forðast óvæntar uppgötvanir í framleiðslu.
Markmynd fyrir FireDAC‑arkitektúr: stöðugt, prófanlegt, viðbyggjanlegt
BDE‑útskipti ætti ekki að enda í „FireDAC alls staðar einhvern veginn“. Sterk markmynd er sérstaklega verðmæt ef forritið á að þróast áfram eða vera hluti af þjónustum/portalum.
Lágmarksmarkmið: samræmdur Connection‑lag (Connection‑Layer)
Í stað dreifðra tenginga í formum er skynsamlegt að hafa miðlægan Connection‑layer:
- Sköpun og uppsetning á TFDConnection á einum stað
- Einingu samræmdar timeouts, encoding/characterSet, villumeðhöndlunar
- Skipta milli Dev/Test/Prod án handlegra aðgerða
- Valkvætt: miðstýrð virkjun tracing/monitoring fyrir greiningu
Mælt: skýrar transaktsjónamörk í faglegri rökfræði
Mörg erfðaforrit dreifa gagnabreytingum yfir UI‑atburði. Það eykur áhættu um hlutbundnar uppfærslur og flækir prófanir. Traustur FireDAC‑aðgangur er: Use Case (þjónusta/fagleg rökgjöf) byrjar og endar transaktsjón, ekki UI. Jafnvel í hreinni VCL‑skjánotkun myndast sterkur kjarni sem síðar er auðveldara að nota sem þjónustu eða API.
Viðbyggjanlegt í átt að þjónustum og REST
Sá sem síðar bætir við REST‑þjón, rekur Windows‑ eða Linux‑þjónustur eða tengir viðskiptavinaportal, nýtur góðs af hreinum gagnalag. FireDAC hentar vel ef connection‑management, villumeðhöndlun og – eftir þjónustulóði – pooling eru hugsuð sem markmynd. Þetta þarf ekki að vera útfært í fyrsta skrefi, en ætti ekki að loka fyrir arkitektúrinn.
Flutningsstefna: innleiða FireDAC stigvaxandi, taka BDE niður stjórnað
Í B2B‑umhverfi er Big‑Bang sjaldan raunhæfur: of margir fagferlar, of mikil rekstrarábyrgð, takmörkuð þolinmæði fyrir löngum niðurtímum. Stigvaxin BDE‑útskipti er yfirleitt öruggari leið.
Fasi 1: Staðaúttekt og áhættakort
Nýtanlegt yfirbragð telur ekki aðeins upp íhluti heldur metur atferli og tengingar:
- Hvaða gagnagrunnar eru notaðir: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
- Hvar eru TTable‑aðgerðir, hvar er SQL notað með TQuery, hvar eru Stored Procedures?
- Hvernig eru transaktsjónir lifaðar í dag (skýrt, óskýrt, Cached Updates, blönduð mynstur)?
- Hvaða skýrslur/útflutningar gera ráð fyrir tilteknum dataset‑eiginleikum (röðun, síur, computed reitir)?
- Hvaða þriðju aðila íhlutir eða innbyggð ramma eru BDE‑sértæk?
Úr þessu áhættakorti kemur í ljós hvort útskipti snúast „aðeins“ um aðgengi eða hvort gagnagrunnsbreyting (t.d. Paradox → SQL Server/PostgreSQL/MariaDB) er skynsamleg eða nauðsynleg samhliða.
Fasi 2: FireDAC‑grunnur (án UI‑breytinga)
Áður en þið flytjið skjái ætti FireDAC tæknilega að standa hreinn:
- Miðlægt DataModule eða þjónustuklasi með TFDConnection
- Uppsetningarmódel fyrir connection‑strings (t.d. INI/JSON) og örugg meðhöndlun leyndarmála
- Staðlað villumeðhöndlun (umbreyta DB‑exceptions í skiljanlegar, skráðar tilkynningar)
- Tracing/monitoring‑valkosti fyrir pilotsvæði (virkjast markvisst, ekki stöðugt „hávær“)
Það er mikilvægt að það myndist bindandi staðlar: nöfn, reglur um parametra, logging‑snið, default‑stillingar eftir gagnagrunni.
Fasi 3: Pilotmódel með raunverulegri faglegri þýðingu
Gott pilot‑svæði er faglega afmarkað en í raunlegri notkun. Markmið: þróa mynstur og sannreyna þau.
- TQuery → TFDQuery (þ.m.t. parametrisering og týpufesting)
- Skilgreina transaktsjónaramma og gera hann sýnilegan í kóðanum
- Sanna jafngildi niðurstaðna (bera saman faglega viðeigandi result‑sett)
- Mæla frammistöðu (svörunartímar, DB‑álag, netumferð)
Að lokum ætti innri athugasemdalisti að liggja fyrir sem hvert næsta einingarkafla er fluttur eftir. Það minnkar áhættu og gerir kostnað áætlanlegri.
Fasi 4: Breiðfletting og hreinsun í deployment
Eftir pilot er farið að skipta yfir kafla fyrir kafla. Samhliða er BDE tekið út sem rekstrarfyrirbæri:
- Fjarlægja installer‑skripti og skjöl um BDE‑uppsetningar
- Fjarlægja alias‑skilgreiningar, NetDir‑stillingar og sérstíga
- Stilla build/release‑pipelines á nýjar hæðir (client‑libs, drifara)
Serstaklega mikilvægur er þessi uppbyggilegi niðurrif: svo lengi sem hlutar af BDE lifa í útgáfu, heldur rekstraráhættan áfram að vera til staðar.
Steinaþröskuldar: algeng orsök faglegra hliðarverkana
Margar flutningar mistakast ekki vegna FireDAC sjálfs, heldur vegna duldra forsendna í gömlum kóða. Þessi svið þarf að forgangsraða snemma.
SQL‑tungumál og sögulega uppsafnaður SQL
BDE‑forrit innihalda oft SQL sem „tilviljun“ virkaði með ákveðnum drifara: dulin joina, ósamræmd notkun aliasa, gagnagrunnssértækar föll, óljósar röðanir. Við flutninginn gildir:
- Gera SQL skýrt (JOIN‑setning í stað dulinrar WHERE‑tengingar)
- Skoða varnarorð og identifiera (t.d. DATE, USER, ORDER sem dálkanöfn)
- Samhæfa dagsetninga/strengja‑föll eða pakka þau inn
FireDAC býður stillimöguleika, en varanleg lausn er DB‑samræmt, læsilegt SQL.
Gagnatýpu‑mappun: Boolean, dagsetning/tími, Memo/Blob, NULL
BDE túlkaði margt í framkvæmd. FireDAC er nákvæmari – sem er gott, en kallar á skýr reglur. Algeng atriði:
- Boolean: BIT/SMALLINT/CHAR(1) – skilgreina faglega skýrt, engar duldar umbreytingar
- Dagsetning/tími: DATETIME vs. DATETIME2, millisekúndur, röðunar-/samanburðarrök; tímabeltaskipti í dreifðum kerfum
- Memo/Blob: Fetch‑atferli (OnDemand), encoding, minnisnotkun í client
- NULLability: Gamall kóði sem blandar saman tómum strengjum og NULL leiðir til illa sýnilegra rökfræðivilla
Sannað er að hafa þunnan gagnatýpu‑kafla: fyrir hverja faglega mikilvæga töflu/dálk markgagnatýpu (DB og Delphi) auk reglu um NULL, sjálfgefið gildi og formötun.
Transaktsjónir: frá duldum að meðvitaðri stjórn
Í erfðaforritum Delphi er algengt að kerfið byggi á duldum commits („þegar ég loka þessu dataseti er það vistað“). FireDAC býður skýrar APIs (StartTransaction, Commit, Rollback). Nútímavæðinginn bætir þegar transaktsjónir eru skilgreindar sem faglegur rammur:
- Use Case byrjar transaktsjón
- Fjölmargar uppfærslur keyra innan sömu Connection
- Commit/Rollback fer fram miðlægt með rekjanlegri villumeðhöndlun
Það minnkar ósamræmi og er lykilatriði þegar forritið verður síðar aukið með þjónustum eða tengjum.
Cached Updates og ágreiningur (Concurrency)
Mörg BDE‑forrit nota Cached Updates sem „offline‑edit“ aðferð. FireDAC getur gert eitthvað svipað, en reglur þurfa að vera skýrar:
- Hvaða reitir eru lyklar, hvaða reitir notaðir til að sannreyna concurrency?
- Hvernig leysa menn ágreining (RowVersion/Timestamp, „last write wins“, notendavali)?
- Hvað gerist við hlutvillur í lotu‑aðgerðum?
Í nútímavæðingum er oft skynsamlegt að færa ágreiningstjórn nær faglegri rökræðu eða í þjónustulag frekar en að fela hana alfarið í UI‑dataset‑hegðun.
TTable/Paradox‑háðar lausnir: FireDAC er ekki eina verkefnið
Ef forritið byggir mikið á skrábundnum aðgangi (TTable á Paradox) er „BDE í staðinn FireDAC“ aðeins hluti af sögunni. FireDAC er fyrst og fremst ætlað fyrir SQL‑gagnagrunna. Þá er mikilvæg spurning: Mun gagnageymsla færast yfir á þjónustugagnagrunn?
- Flutningur í SQL Server, PostgreSQL eða MariaDB
- Innleiðing hlutverk-/aðgangsstefnu og hreinna backup/restore‑ferla
- Stöðugur fjölnotendarekstur án skrár‑lásavandamála
Ef gagnagrunnsbreyting er ekki strax möguleg er oft raunhæft að fara tvenns konar leið: fyrst festa aðgangslagið og draga úr UI‑tengingu, síðan gagnamigration með skýrum prófunar‑ og cutover‑ferli.
Skýrslugerð, útflutningar og þriðju aðilar
Skýrslur eru oft háðar smáatriðum: röð, síur, reiknaðir reitir, Master/Detail‑eiginleikar. Fyrir stjórnanlega breytingu:
- Finna lykilskýrslur og meðhöndla þær sem regression‑prófunarsöfn
- Mynda gagnasett fyrir skýrslur á fyrirsjáanlegan hátt (Views/Stored Procedures eða vel skilgreindar queries)
- Draga úr UI‑síaferlum sem treysta á dataset‑atferli
Markmiðið er endurleitarlegt jafngildi niðurstaðna, einkum hjá útgáfum sem eiga í endurskoðunarskyldum útreikningum.
Arkitektúru‑uppfærsla í tengslum við FireDAC‑flutning: pragmatiskt aðskilja
BDE‑útskipti er hentugur tími til að færa gagnaaðgang úr formum og event‑handlerum. Þetta krefst ekki algjörrar endurarkitektúru. Jafnvel íhaldssamar aðgerðir hafa oft veruleg áhrif.
Pragmatísk markbygging (tengjanleg við Layer‑3 arkitektúr)
- Connection/Unit‑of‑Work: stjórnar Connection og transaktsjón, útvegar Query‑hluti
- Repository/DAO: pakka SQL og gagnaaðgang per faglegt svið
- Service/Use Case: samstýrir faglega logík, staðfestingar og transaktsjónaramma
Þessi uppbygging er samrýmanleg síðarlegri Layer‑3 arkitektúr og auðveldar áframhaldandi verkefni: REST‑viðmót, bakgrunnsþjónustur, fjölpallaklientar eða tenging við portala.
Mikilvægur ávinningur: færri víðtækar hliðarverkanir
Mörg BDE‑verkefni nota global gagnamodúla og duldar stöður. FireDAC virkar einnig þannig, en nútímavæðingin verður stöðugri ef stöður eru staðbundnar: skýr líftími Connection/transaktsjónar, endurleitarleg villuleið, færri „aukaverkanir“ frá globalum stöðum.
Frammistaða og stöðugleiki: stilla FireDAC markvisst
FireDAC er afkastamikið, en frammistaða er samspil SQL, indexa, fetch‑stefnu og connection‑stjórnunar. Í flutningum kemur oft í ljós: BDE huldi óhagkvæm mynstur því gagnamagn var áður minna eða kerfið keyrði staðbundið.
Fetch‑stefnur og UI‑listar
- Hlaða aðeins þá dálka sem þarf (ekki SELECT *)
- Server‑hliðarröðun og markvisst síun í stað client‑hliðarröðunar
- Við stór gagnamagn: paging eða smám saman hleðsla
- LOB‑reitir (Memo/Blob) aðeins hlaða þegar raunverulega þarf
FireDAC býður viðeigandi valkosti; það er fagleg ákvörðun hvaða gögn notandi þarf hvert sinn.
Prepared Statements og parametrisering
Parametriseruð queries eru ekki aðeins öryggisstaðall (forðast SQL‑injektion) heldur bæta endurnýtingu plöns í mörgum gagnagrunnum. Jafnframt koma týpuóreinar í gömlum kóða fram og má laga þær markvisst. Í uppsöfnuðum kerfum er þetta gæðauppfærsla sem sýnir sig í færri undantekningum og betri greiningu.
Connection‑stjórnun: Desktop vs. Service/REST
Í hefðbundnum skjáborðsviðskiptavinum er oft hentugt að hafa langlífa Connection per viðskiptavin. Í þjónustum eða REST‑þjónum er venjulega annað mynstur: styttri beiðnir, samtímahæfur aðgangur, connection‑pooling. Sá sem lítur á BDE‑útskipti sem hluta af stærri nútímavæðingu ætti að hafa þessar munandi markmyndir í huga svo síðarri útbyggingar byrji ekki upp á nýtt með gagnaaðganginn.
Prófunar‑ og móttekningarstefna: sanna niðurstöðu‑jafngildi
Hætta í BDE‑útskipti er sjaldan „forritið byrjar ekki“, heldur hljóðar faglegar frávik: röðun, ummörkun, NULL‑höndlun, transaktsjónamörk, aukaverkanir triggers/constraints í nútíma DB. Traust prófunarstefna felur í sér:
- SQL‑regression: keyra lykilfyrirspurnir á skilgreindum prófunargögnum og bera saman result‑sett
- Use‑Case‑prófanir: kanna kjarnferla (t.d. bókun, staðfesting, ógilding, innflutning/útflutning) með væntigildum
- Fjölnotenda‑/stöðugleikapróf: læsingar, deadlocks, timeouts, transaktsjónalengd
- Logging/observability: skrá DB‑villur strúktúrað (villukóðar, samhengið, fyrirspurn), ekki aðeins „villa‑gluggi“
Fyrirtæki njóta tvöfalds ávinnings: Prófanir tryggja flutninginn og skapa grundvöll til að stjórna framtíðarbreytingum á gagnalíkani eða viðmótum.
Markgagnagrunnar í FireDAC‑verkefnum: algengar kostir
FireDAC er víðtækur, en hver gagnagrunnur hefur sínar reglur. Í nútímavæðingum eru eftirfarandi mark oft valin:
SQL Server
Algengt í Windows‑ráðandi IT‑umhverfum. Mikilvæg atriði: samræmd Unicode‑týpur (NVARCHAR), nútíma tímatýpur (DATETIME2), skýr Identity/Sequence‑stefna, skilgreind isolation‑levels og vönduð meðhöndlun læsinga.
PostgreSQL
Sterkur í gagnasamræmi og eiginleikum. Í flutningum þarf að huga að: case‑sækni identifiera, gagnatýpum (boolean/uuid/jsonb) og mun á málfræði. FireDAC getur tengst PostgreSQL í framleiðslu um leið og client‑bókasöfn og deployment eru vel skipulögð.
MariaDB/MySQL
Algengt þegar skjáborðsforrit vinna með vef‑ eða portal‑hlutum. Mikilvægt: nota utf8mb4 alls staðar, InnoDB sem engine, og vanda transaktsjónar‑ og index‑stefnu. FireDAC styður MariaDB/MySQL áreiðanlega ef parametrar og týpur eru skýrt skilgreindar.
Sama hver markgagnagrunnurinn er: BDE‑útskipti er stöðugast ef gagnagrunnsstaðlar eru settir á fót samtímis (schema‑útgáfustjórnun, migration‑skript, hlutverk/aðgangar, backup/restore, monitoring).
Hagnýtar ráðleggingar fyrir áætlaða FireDAC‑flutninga
Draga úr háðum þáttum áður en fjöldaskipti á íhlutum hefjast
Ef SQL og dataset‑rök eru innbyggð í mörgum formum verður hver breyting dýr. Milliskref sem safnar SQL í fáar aðgangstengdar klasa minnkar flutningsflöt verulega. Eftir það er sjálf skiptingin yfir í FireDAC oft hraðari og með minni áhættu.
Flytja snemma transaktsjónalegt kjarnaferli
„Auðveldir listar“ eru þægileg inngangur, en minnka áhættu er að flýta fyrir flutningi ferils með raunverulegum uppfærslum og háðni. Ef transaktsjónir, gagnatýpur og villuleiðir eru þar hreinar verður restin áætlanlegri.
Taka deployment sem jafnframt vinnu
Kóðabreyting er aðeins hálfur sigur. Leitið svara snemma:
- Hvaða client‑bókasöfn/drifara þarf fyrir hvern gagnagrunn?
- Hvernig verða þau útgáfu‑stýrð, undirrituð (ef við á) og dreift?
- Hvernig eru connection‑parametrar stjórnaðir og hver hefur rétt til að breyta þeim?
- Hvernig lítur stuðningsferlið út ef DB‑aðgangur bilar?
Nota FireDAC sem nútímavæðingarjókstafa – án aðkomu við allt frá grunni
Útskipti eru tækifæri til að beita gæðahöggum: parametrisering, transaktsjónarmörk, logging, samræmd villutexta. Þessi skref lágmarka rekstrarkostnað og gera síðarlegar breytingar (viðmót, þjónustur) mun auðveldari án þess að breyta faglegu efninu frá grunni.
Niðurstaða: BDE‑útskipti með FireDAC er stjórnanleg nútímavæðing – ef hún er með arkitektúrlegu tilliti
BDE hefur borið mörg Delphi‑forrit í mörg ár. Í dag er hún hins vegar uppbyggingar‑áhætta: fyrir 64‑bita, staðlaða útgáfusendingu, nútíma öryggiskröfur og tengingu við samtíma gagnagrunna. FireDAC er hentugur eftirmaður, en ekki sem „íhlutaskipti yfir nótt“. Örugg leið er stigvaxin migration með hreinni grunnuppsetningu, pilot‑módel, bindandi reglur um gagnatýpur og transaktsjónir og prófanir sem sannreyna niðurstöðu‑jafngildi.
Ef þið viljið skipuleggja BDE‑útskipti með kerfisbundnum hætti – þar með talið staðaúttekt, migrasjónarleið og FireDAC‑markarkitektúr – er tæknilegur samanburður rammaskilyrða skynsamlegasta næsta skrefið: https://net-base-software-gmbh.de/kontakt/