Að skipta Borland BDE út fyrir FireDAC: Leiðarvísir fyrir örugga Delphi-nútímavæðingu án Big Bang

Í mörgum fyrirtækjum er Borland Database Engine (BDE) enn í dag hluti af viðskiptafræðilega mikilvægar Delphi-lausnum: uppbyggð fagleg rökfræði, gagnanotkun nærri notendaviðmóti með TTable/TQuery, sumstaðar enn Paradox/dBase og annars staðar fyrstu Client/Server-uppsetningar. Raunin er oft sú að hugbúnaðurinn keyrir, notendur þekkja ferlana og í daglegum rekstri er enginn beinn hvati til að „snerta neitt“. Á sama tíma breytist tæknilegur grunnur: stýrikerfi eru herdd, uppsetningarkerfi eru staðluð, 64‑bita er vænst og gagnageymsla þarf að vera á gagnagrunnsþjónum með skýru aðgangs- og afritunarhugtaki.

Einmitt þar breytist „Borland BDE durch BDE-Ablösung mit nativer Anbindung ersetzen“ í stefnumótandi verkefni um endurnýjun. BDE-Ablosung mit nativer Anbindung er í núverandi Delphi-útgáfum viðurkenndur aðgangur að nútímagagnagrunnum. Hann skilar samkvæmu hegðunarmynstri, traustum bílstjórum, Unicode-stuðningi, mælingum/rekjanleika og arkitektúr sem þjónar bæði skjáviðmótum, þjónustum og REST-þjónum. Skiptingin er sjaldan einfaldlega 1:1 íhlutaskipti – sérstaklega ekki ef eldri forritið hefur byggt inn BDE-sértæka hegðun í áraraðir (forsendur um viðskiptajafna, gagnasnið, síur/röðun, Cached Updates, þriðju aðila skýrslugerðir).

Þessi grein beinist að hagnýtu verklagi: Hvernig skipta þú BDE út fyrir FireDAC án þess að ógna faglogík og án þess að neyða fram stóra Big‑Bang-endurræsingu? Þú færð framkvæmanlegt módel, tæknileg markmynd og ábendingar um venjuleg vandasvæði í rekstri fyrirtækja.

Af hverju er BDE-Ablösung í dag meira en bara tækniþjónusta

Svo lengi sem BDE-forrit virkar, lítur aflétting oft út eins og hreinsun á kóða. Í reynd kemur þrýstingurinn þó venjulega frá rekstri og áhættumálum.

Deployment, Security-Baselines und „No-Touch“-Clients

BDE var upphaflega hannað fyrir staðbundna stillingu (BDE Administrator, Alias-Definitionen, NetDir, sameiginlegar stillingarskrár). Í nútímaumhverfi passar handvirkar aðgerðir og kerfisstillingar illa við hugbúnaðarúthlutun, herdingu og endurskoðanleika. FireDAC gerir mun betur stjórnleg dreifingar mögulegar, því tengiparametrar og bílstjórastillingar má halda nálægt forritinu.

64‑Bit, Windows-Modernisierung und neue Plattformziele

Ef forrit þarf að keyra í 64‑bita umhverfi (minnisþörf, bílstjórar/Office‑vistkerfi, nýr búnaður, Terminal‑server‑stefna), verður BDE í reynd hindrun. FireDAC styður 32/64‑bita á samræmdan hátt og er því kjarnabútur í hverri Delphi Modernisierung sem má ekki mistakast vegna gagnaaðgangs. Jafnframt verða efni eins og Windows 11 ARM64 og hybrid‑Client/Service‑arkitektúrar yfirleitt fyrirsjáanlegri.

Datenbankstrategie: weg von dateibasiert, hin zu serverbasiert

Mörg BDE-forrit bera enn með sér arfleifð frá Paradox/dBase‑tímum. Slík skránna gögn eru viðkvæmari í fjölnotendarekstri, erfiðari í afritunarstjórnun og passa illa við nútímakröfur (hlutverk/aðgangsstýring, dulkóðun, mælingar, háframboð). FireDAC er ekki „nýi Paradox‑bílstjórinn“, en er nútímalegur aðgangur að SQL Server, PostgreSQL, MariaDB og Firebird. Í reynd er BDE-Ablösung því oft upphafið að því að faglega skipuleggja gagnageymslu og rekstur.

Wartbarkeit und Diagnosefähigkeit im Betrieb

Vanmetinn kostnaðarþáttur er bilanaleit: sporadísk læsingarvandamál, ósamræmi í cursor‑hegðun, illa fylgjandi parameter‑umbreytingar eða net-/stígvandræði. FireDAC býður með logging, monitoring og skýrari týpuhegðun betri forsendur fyrir endurtekningarhæfri greiningu. Fyrirtæki sem ætla að reka forrit til langs tíma og bæta það smám saman fá strax beinan ávinning.

BDE vs. FireDAC: Unterschiede, die in der Migration zählen

Á blaði má para saman íhluti. Í reynd snýst málið um breytingar á hegðun sem geta haft faglegar hliðarverkanir. Stutt leiðarvísir:

Komponenten-Mapping (als Startpunkt)

• TDatabase (BDE) → TFDConnection (FireDAC)
• TQuery (BDE) → TFDQuery
• TTable (BDE) → TFDTable (í endurnýjun er oft betra: Query-/View‑byggður aðgangur)
• TStoredProc (BDE) → TFDStoredProc

Die häufigsten Verhaltensdifferenzen

• Parameter und Datentypen: FireDAC vinnur nákvæmar. „Það verður nú allt í lagi“ SQL kemur fyrr upp (t.d. dagsetningar sem strengi, dulin umbreyting, óljós nullability).
• Transaktionen: Erfðakóði inniheldur oft duldar forsendur um commit (lokun dataset, AutoCommit‑líkar venjur, Cached Updates). Með FireDAC borgar sig að stýra viðskiptum meðvitað, því það eykur faglega stöðugleika.
• Cursor/Fetch: FireDAC hefur önnur sjálfgefin gildi og fleiri stillingarmöguleika. Óhagkvæm mynstur (stór result‑sett fyrir UI‑lista) verða sýnilegri, en hægt er að fínstilla þau markvisst.
• Unicode: Í nútíma Delphi-útgáfum er Unicode sjálfgefið. FireDAC‑keðjan (Client‑Library, Connection‑Options, DB‑Collation, reitategundir) verður að vera samstillt, annars hætta á stafa‑ og samanburðarvanda.
• Deployment: Fer eftir gagnagrunni hvort klientbókasöfn eru nauðsynleg (t.d. libpq fyrir PostgreSQL). Þetta þarf að skipuleggja snemma til að forðast óvæntar birtingar í framleiðslu.

Zielbild für eine FireDAC-Architektur: stabil, testbar, erweiterbar

BDE-Ablösung ætti ekki að enda í „FireDAC überall irgendwie“. Traust markmynd er sérstaklega verðmæt þegar forritið á að þróast áfram eða vera innbyggt í þjónustur/vefviði.

Minimalziel: einheitlicher Connection-Layer

Í stað dreifðra tenginga í formum er mælt með miðlægum Connection‑lagi:

• Sköpun og uppsetning á TFDConnection á einum stað
• Einingartímar, Encoding/CharacterSet, villumeðhöndlun
• Skipting Dev/Test/Prod án handvirkrar eftirvinnslu
• Valkvætt: miðlæg virkni fyrir Tracing/Monitoring til greiningartilvika

Empfohlen: klare Transaktionsgrenzen in der Fachlogik

Mörg eldri kerfi dreifa gagnabreytingum yfir UI‑events. Það eykur hættu á hlutbundnum uppfærslum og gerir prófanir erfiðari. Stöðugur FireDAC‑aðgangur byggir á því að Use Case (þjónusta/faglogík) hefji og ljúki viðskiptum, ekki UI. Jafnvel í hreini VCL‑skjáforritum myndar það traustan kjarna sem síðar er auðveldara að nota sem þjónustu eða API.

Erweiterungsfähig Richtung Services und REST

Sá sem bætir síðar við REST-Server, rekur Windows‑ eða Linux‑þjónustur eða vill tengja við viðskiptavinaportal, græðir á hreinum gagnalag. FireDAC hentar því ef Connection‑stjórnun, villumeðhöndlun og – eftir álagi á server – poolun eru hugsuð sem markmynd. Þetta þarf ekki að vera innleitt í fyrsta skrefi, en það má ekki spilla arkitektúrnum fyrir síðarnefndar viðbætur.

Migrationsstrategie: FireDAC schrittweise einführen, BDE kontrolliert zurückbauen

Í B2B‑umhverfum er stórt Big‑Bang sjaldan raunhæft: of margir fagferlar, of mikil rekstrarábyrgð og of lítill vilji fyrir löngum niðurlögum. Skref fyrir skref BDE‑Ablösung er yfirleitt öruggari leið.

Phase 1: Bestandsaufnahme und Risikokarte

Góð rannsókn telur ekki aðeins íhluti heldur metur hegðun og tengsl:

• Hvaða gagnagrunnur(-ar) eru í notkun: 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 viðskipti meðhöndluð í dag (skýr, dulin, Cached Updates, blandaðar venjur)?
• Hvaða skýrslur/úttök ætla sér ákveðna Dataset‑eiginleika (röðun, síun, Calculated Fields)?
• Hvaða þriðju aðila íhlutir eða eigin ramma eru BDE‑sértækir?

Úr þessum korti verður ljóst hvort aflétting varðar aðeins aðgang eða hvort gagnabreyting (t.d. Paradox → SQL Server/PostgreSQL/MariaDB) er ráðleg eða nauðsynleg.

Phase 2: FireDAC-Foundation (ohne UI-Umstellung)

Áður en skjár eru fluttir ætti FireDAC tæknilega að vera staðbundinn:

• Miðlægt DataModule eða þjónustuflokkur með TFDConnection
• Uppbygging fyrir Connection‑strengja (t.d. INI/JSON) og örugg meðferð leyndarmála
• Staðlað villumeðhöndlun (breyta DB‑exceptions í skiljanlegar, logg‑vænar tilkynningar)
• Tracing/Monitoring‑valkostir fyrir pilothlaup (virkjast markvisst, ekki alltaf „hátt“)

Það er mikilvægt að úr þessu verði bindandi staðlar: nafnavenjur, reglur um parametra, logging‑skema og sjálfgefin stilling fyrir hverja gagnagrunnstegund.

Phase 3: Pilotmodul mit echter Fachrelevanz

Gott pilot‑svæði er faglega afmarkað en í notkun. Markmiðið er að þróa og sannreyna mynstur.

• TQuery → TFDQuery (þ.m.t. parameterisering og týpusetning)
• Skilgreina viðskiptaramma og gera hann sýnilegan í kóða
• Sanna niðurstöðujafnveru (bera saman faglega mikilvægar result‑sett)
• Mæla frammistöðu (svörunartími, DB‑álag, nettó‑umferð)

Að lokum ætti að liggja fyrir innri athugunarlisti sem hvert næsta einingar‑modul er fært yfir eftir. Það dregur úr áhættu og gerir vinnuframvindu áætlanlegri.

Phase 4: Flächenmigration und Deployment-Bereinigung

Eftir pilot er stigsfar breytingu lokið eftir einingum. Á sama tíma er BDE dregið smám saman út úr rekstri:

• Fjarlægja installer‑skript og skjöl sem tengjast BDE‑uppsetningum
• Fjarlægja Alias‑skilgreiningar, NetDir‑uppsetningar og sérstíga
• Sníða build-/release‑pípur að nýjum háðarþáttum (Client‑Libs, bílstjórar)

Þessi niðurtaka er sérstaklega mikilvægt: svo lengi sem BDE‑hlutar lifa í dreifingu, helst rekstraráhættan til staðar.

Stolperstellen: häufige Ursachen für fachliche Seiteneffekte

Margar uppfærslur mistakast ekki vegna FireDAC, heldur vegna hulinna forsendna í eldri kóða. Þessi svið ætti að forgangsraða snemma.

SQL-Dialekte und historisch gewachsenes SQL

BDE-forrit innihalda oft SQL sem „bara spilaði“ með tilteknum bílstjóra: dulin joins, óregluleg alias‑notkun, DB‑sértækar aðgerðir, óákveðnar röðanir. Í flutningi gildir:

• Gera SQL skýrt (JOIN‑táknfræði í stað duldra WHERE‑tenginga)
• Athuga reserved words og identifiera (t.d. DATE, USER, ORDER sem reitarnöfn)
• Samhæfa eða loka inn á dagsetninga-/tíma‑ og strengjaaðgerðir

FireDAC býður aðlögunarvalkosti, en varanlega rétta lausnin er DB‑samræmt, lesanlegt SQL.

Datentyp-Mapping: Boolean, Datum/Zeit, Memo/Blob, NULL

BDE túlkaði í reynd mikið. FireDAC er nákvæmari – sem er gott, en krefst skýrra reglna. Algeng mál:

• Boolean: BIT/SMALLINT/CHAR(1) – skilgreina faglega skýrt, ekki treysta duldum umbreytingum
• Datum/Zeit: DATETIME vs. DATETIME2, millisekúndur, röðun-/samanburðarhegðun; tímabeltamál í dreifðum kerfum
• Memo/Blob: Fetch‑hegðun (OnDemand), encoding, minnisnotkun í klient
• NULLability: Eldri kóði sem blönduð hefur tóma strengi og NULL leiðir til erfitt uppgötvana rökleysa

Sannreynt er að viðhalda léttum gagnategundarkafla: fyrir hverja faglega mikilvæga töflu/reit skilgreina marktegundir (DB og Delphi) ásamt reglum um NULL, sjálfgefin gildi og format.

Transaktionen: von implizit zu bewusst orchestriert

Í Legacy‑Delphi‑verkefnum er algengt að kerfið treysti duldum commit‑venjum („ef ég loka datasetinu er það vistað“). FireDAC býður skýrar API‑aðferðir (StartTransaction, Commit, Rollback). Endurnýjunarhagnýtingin kemur þegar viðskipti eru skilin sem faglegur ramma:

• Use Case byrjar viðskipti
• Fjöldi uppfærslna fer fram innan sömu Connection
• Commit/Rollback fer fram miðlægt með rekjanlegri villumeðhöndlun

Þetta dregur úr ósamræmi og er lykilatriði ef forritið á eftir að stækka með þjónustum eða viðmótum.

Cached Updates und Konfliktbehandlung (Concurrency)

Mörg BDE-kerfi nota Cached Updates sem „offline‑edit“ mekanisma. FireDAC getur gert svipað en reglurnar þurfa að vera skýrar:

• Hvaða reitir eru lyklar, hvaða reitir eru notaðir í samkeppnisprófi?
• Hvernig eru árekstrar leystir (RowVersion/Timestamp, „last write wins“, notendaval)?
• Hvað gerist við hlutvillur í lotu‑aðgerð?

Í endurnýjun er oft skynsamlegt að færa árekstralógíkina nær faglogik eða í þjónustulag frekar en að fela hana aðeins í UI‑dataset‑hegðun.

TTable/Paradox-lastige Anwendungen: FireDAC ist nicht die einzige Baustelle

Ef forrit byggir mikið á skránnaaðgangi (TTable á Paradox) er „BDE durch FireDAC“ aðeins hluti sannleikans. FireDAC er fyrst og fremst ætlað fyrir SQL‑gagnagrunna. Þá er grundvallarspurningin: Ætla að færa gagnageymslu yfir á server‑DB?

• Flutningur í SQL Server, PostgreSQL eða MariaDB
• Innleiðing hlutverka/aðgangsstýringar og góðs backup/restore ferlis
• Traustur fjölnotendarekstur án file‑locking vandamála

Ef tafarlaus gagnabreyting er ekki færanleg vegna skipulagslega ástæðna er oft hagnýtt tvenns konar nálgun: fyrst styrkja aðgangslag og minnka UI‑tengingu, síðan gagnamigration með skýrum prófunar‑ og cutover‑stefnum.

Reporting, Exporte und Drittkomponenten

Skýrslur bera oft á sér smáatriði: röðun, siuferð, útreiknaðar reitir, Master/Detail‑hegðun. Fyrir stýrðan flutning:

• Greina út hvaða skýrslur eru gagnrýnar og meðhöndla þær sem regression‑test‑safn
• Framleiða gagnapakka fyrir skýrslur á ákvarðanalegan hátt (Views/Stored Procedures eða vel skilgreindar queries)
• Minnka UI‑síukvörðun sem treystir á dataset‑hegðun

Markmiðið er endurleikjanleiki í niðurstöðum, sérstaklega fyrir endurskoðunarkröfur.

Architektur-Upgrade im Zuge der FireDAC Migration: pragmatisch entkoppeln

BDE-Ablösung er góður tími til að losa gagnaaðgang úr formum og event‑handlerum. Það þýðir ekki að allt þurfi að endurarkitektúra. Jafnvel hóflegar aðgerðir hafa oft veruleg áhrif.

Pragmatische Zielstruktur (anschlussfähig an Layer-3-Architektur)

• Connection/Unit-of-Work: heldur utan um Connection og viðskipti, veitir Query‑hluti
• Repository/DAO: umlykur SQL og gagnaaðgang fyrir hvern faglegan þátt
• Service/Use Case: stjórnar faglogik, gildisskoðunum og viðskiptaramma

Þessi uppbygging er samhæfanleg síðar Layer-3 Architektur og auðveldar framhaldverkefni: REST‑snið, bakgrunnsþjónustur, margpallaviðmót eða tengingu við portala.

Wichtiger Effekt: weniger globale Seiteneffekte

Mörg BDE‑verkefni nota globalt DataModules og duldar stöður. FireDAC virkar ennþá þannig, en endurnýjun verður stöðugri ef stöður eru staðbundnar: skýr lífsferill Connection/Transaction, endurleitanleg villuflæði, færri „aukaverkanir“ af globalri stöðu.

Performance und Stabilität: FireDAC gezielt konfigurieren

FireDAC er afkastamikill, en frammistaða er samsetning SQL, indexa, fetch‑stefnu og connection‑stjórnunar. Í flutningum kemur oft í ljós að BDE huldi óhagkvæm mynstur vegna þess að gagna‑magn voru áður minni eða kerfið var staðbundið.

Fetch-Strategien und UI-Listen

• Lista hlaða aðeins nauðsynlega dálka (ekki SELECT *)
• Server‑side röðun og markviss síun í stað client‑hliðra keðja
• Við mikið gagnafjölda: paging eða stigvaxandi hleðslu
• LOB‑reit (Memo/Blob) nær aðeins hlaðinn þegar hann er þörf

FireDAC býður viðeigandi valkosti; lykilatriðið er fagleg ákvörðun um hvaða gögn notandi þarf í hverju samhengi.

Prepared Statements und Parametrisierung

Parametrized queries eru ekki aðeins öryggisstaðall (forðast SQL‑Injection) heldur bæta endurnotkun plana í mörgum gagnagrunnum. Einnig birta þau týpuóreiðu í eldri kóða sem hægt er að leiðrétta markvisst. Sérstaklega í uppsafnaðri kóða er þetta gæðauppfærsla sem leiðir til færri undantekninga og betri greiningarhæfni.

Connection-Management: Desktop vs. Service/REST

Í hefðbundnum skjáviðmótaklientum er oft hentugt að hafa langlífa Connection fyrir hvern klient. Í þjónustum eða REST‑þjónum eru önnur mynstur: skammlífar beiðnir, samhliða aðgengi, connection‑pooling. Sá sem lítur á BDE‑Ablösung sem hluta af stærri endurnýjun þarf að taka þessi munar í markmynd svo síðar útvíkkun byrji ekki upp á nýtt vegna gagnaaðgangs.

Test- und Abnahmestrategie: Ergebnisgleichheit nachweisen

Í BDE‑Ablösung er helsta áhættan sjaldan „forritið ræsist ekki“, heldur hljóðar faglegar frávik: röðanir, nákvæmni, NULL‑meðhöndlun, viðskiptafleti, aukaverkanir triggera/constraints í nútíma DB. Traust prófunarstefna inniheldur:

• SQL‑Regression: keyra krítískar fyrirspurnir á skilgreindum próf‑gögnum og bera saman result‑sett
• Use‑Case‑Tests: prófa kjarnferla (t.d. bókun, samþykkt, afturköllun, innflutning/úttak) með væntanlegum niðurstöðum
• Mehrbenutzer-/Stabilitätstests: læsingarhegðun, deadlocks, timeouts, lengd viðskipta
• Logging/Observability: skrá DB‑villur uppbyggilega (villu‑kóði, samhengi, fyrirspurnin), ekki aðeins „villa‑gluggi“

Fyrirtæki hagnast tvisvar: prófin tryggja flutninginn og leggja grunn að því að frekari breytingar á gagnalíkan eða samskiptum verði framkvæmdar á stjórnlegan hátt.

Zieldatenbanken in FireDAC-Projekten: typische Optionen

FireDAC er meðvitað víðtækt, en hver gagnagrunnur hefur sínar reglur. Í endurnýjun eru eftirfarandi markmið algeng:

SQL Server

Algengt í Windows‑ráðandi kerfum. Mikilvægt: samræmda Unicode‑tegundir (NVARCHAR), nútíma tímatypur (DATETIME2), skýr identity/sequence‑stefna, skilgreind isolation‑stigin og réttháð meðhöndlun læsinga.

PostgreSQL

Sterkt í gagnaheilindi og virkni. Í flutningum mikilvægt: Case‑sækinleiki identifiera, gagnategundir (boolean/uuid/jsonb) og dæmismunur. FireDAC getur tengst PostgreSQL framleiðsluvænt ef client‑libs og dreifing eru vel skipulagðar.

MariaDB/MySQL

Algengt þegar skjáforrit vinna með vef‑ eða portal‑þáttum. Mikilvægt: nota utf8mb4 kerfisbundið, InnoDB sem engine, skýr viðskiptastrategía og index‑stefna. FireDAC styður MariaDB/MySQL áreiðanlega ef parametrar og týpur eru vel skilgreindar.

Óháð markagagnagrunni gildir: BDE‑Ablösung er stöðugust ef samtímis taka upp gagnagrunnsstaðla (schema‑versioning, migration‑script, hlutverk/aðgangur, backup/restore, monitoring).

Praxisempfehlungen für eine planbare FireDAC Migration

Abhängigkeiten reduzieren, bevor Sie in Masse Komponenten tauschen

Ef SQL og dataset‑rök eru dreifð um mörg form verður hver breyting dýr. Milliskref sem safnar SQL í fáar aðgangsflokka minnkar verulega flutningsflötinn. Síðan er sjálf flutningsaðgerðin oft hraðari og öruggari.

Früh einen transaktionalen Kernprozess migrieren

„Einfache Listen“ eru þægilegt byrjunarstykki, en hættuminna er að flytja snemma feril sem framkvæmir raunverulegar uppfærslur og hefur háðartengsl. Þegar viðskipti, gagnategundir og villuflæði eru þar í lagi verður restin áætlanlegri.

Deployment als gleichrangige Arbeit behandeln

Kóðaumbreyting er aðeins helmingur verksins. Leystu snemma:

• Hvaða client‑libs/bílstjóri þarf fyrir hvern gagnagrunn?
• Hvernig verða þessar útgáfur stýrðar og dreifðar (undirskráning ef við á)?
• Hvernig eru Connection‑parametrar stjórnaðir og hver hefur rétt til að breyta þeim?
• Hvernig er stuðningsferli ef DB‑aðgangur bregst?

FireDAC als Modernisierungsanker nutzen – ohne Neuanfang

Afléttingin er tækifæri til markvissra gæðasláa: parametrisering, viðskiptarammar, logging, samræmdir villutekstar. Það minnkar rekstrarkostnað og gerir síðar viðbætur (samskiptaviðmót, þjónustur) mun öruggari án þess að þurfa að endurgera faglegar aðgerðir forritsins.

Fazit: BDE-Ablösung mit FireDAC ist kontrollierbare Modernisierung – wenn sie als Architekturthema behandelt wird

BDE hefur í mörg ár þjónað mörgum Delphi-forritum. Í dag er hún hins vegar uppbyggingarhætta: fyrir 64‑bita, staðlaða dreifingu, nútíma öryggiskröfur og tengingu við samtímagagnagrunna. FireDAC er viðeigandi arftaki, en ekki sem „íhlutaskipti yfir nótt“. Örugg leið er stigvaxandi flutningur með traustri foundation, pilot‑moduli, bindandi reglum um gagnategundir og viðskipti og prófum sem sanna niðurstöðujafnveru.

Ef þið viljið skipuleggja BDE‑Ablösungina – þar með talda stöðumat, migrationsstefnu og FireDAC‑markarkitektúr – er tæknilegur samræmingur á rammaskilyrðum næst skynsamlegi áfanginn: https://net-base-software-gmbh.de/kontakt/