MariaDB csatlakoztatása Delphi és FireDAC használatával: architektúra, illesztőprogram-választás és kiszámítható üzemeltetés

Wer MariaDB mit Delphi und BDE-Ablösung mit nativer Anbindung anbinden will, hat meist mehr im Blick als „nur“ eine erfolgreiche Verbindung. In Unternehmensumgebungen zählen vor allem Betriebssicherheit, klare Konfiguration, reproduzierbare Deployments und ein Datenzugriff, der auch unter Last stabil bleibt. MariaDB wird häufig als kosteneffiziente, gut administrierbare Alternative im MySQL-Ökosystem eingesetzt – und Delphi-Anwendungen sind in vielen Unternehmen gewachsene, prozessnahe Lösungen, die zuverlässig laufen müssen und über Jahre weiterentwickelt werden.

In diesem Beitrag geht es deshalb nicht um Framework-Details oder Demo-Code, sondern um die Entscheidungen, die IT-Leitung und Administration wirklich betreffen: Welche Treiberstrategie ist sinnvoll (native Client-Libraries vs. ODBC), wie vermeiden Sie Zeichensatz- und Collation-Probleme, wie planen Sie TLS sauber ein, welche Transaktions- und Locking-Aspekte sind in MariaDB relevant, und wie bleiben Monitoring, Updates und Fehlersuche im Alltag beherrschbar. Ziel ist eine Anbindung, die nicht nur „geht“, sondern über die Lebensdauer der Business-Software wartbar und auditierbar bleibt.

MariaDB mit Delphi und FireDAC anbinden in der Praxis

MariaDB ist historisch aus MySQL hervorgegangen und ist in vielen Bereichen kompatibel, aber nicht identisch. Für den Betrieb heißt das: Viele Tools, Konzepte und Client-Treiber funktionieren ähnlich, dennoch gibt es Unterschiede bei Features, Standardwerten, Optimizer-Verhalten und teils auch bei Datentypen oder Systemvariablen. Für Delphi/BDE-Ablosung mit nativer Anbindung ist das vor allem bei der Frage relevant, welcher Treiberweg genutzt wird und welche SQL-Dialektannahmen in der Anwendung stecken.

FireDAC ist die Datenzugriffsschicht in Delphi, die viele Datenbanken einheitlich anbinden kann. FireDAC kapselt dabei die Verbindung, Parameter, Transaktionen und Dataset-Verhalten. Wichtig im Unternehmensalltag: FireDAC ist nicht nur „ein Treiber“, sondern eine Schicht, die je nach Datenbank unterschiedliche Treibermodi nutzen kann. Für MariaDB läuft das in der Praxis auf zwei robuste Pfade hinaus: native MySQL/MariaDB-Client-Libraries oder ODBC.

Treiberstrategie: Native Client-Library vs. ODBC – was ist im Betrieb besser?

Die wichtigste Weichenstellung ist, ob Sie FireDAC über eine native Client-Library (aus dem MySQL/MariaDB-Umfeld) oder über einen ODBC-Treiber anbinden. Beide Wege sind technisch valide, unterscheiden sich aber in Deployment, Update-Prozessen und Fehlerbildern.

Native Client-Library (libmysql / MariaDB Connector/C)

Bei der nativen Anbindung arbeitet FireDAC mit einer Client-Bibliothek, die zur Laufzeit verfügbar sein muss (typisch als DLL unter Windows oder als Shared Library unter Linux). In der Praxis begegnen Ihnen zwei Varianten:

• MySQL-Client-Library: weit verbreitet, aber abhängig von Versionen und Distributionswegen.
• MariaDB Connector/C: oft konsistenter für MariaDB-Server, mit eigenem Release-Zyklus.

Betriebssicht: Native Libraries liefern meist die beste Performance und die direkteste Fehlerdiagnose (Handshake, TLS, Authentifizierung). Der Preis ist ein zusätzlicher Deployment-Baustein: Die richtige Library-Version muss auf allen Zielsystemen vorhanden sein und darf nicht „zufällig“ durch andere Software überschrieben werden.

ODBC (MariaDB ODBC Driver)

ODBC (Open Database Connectivity) ist ein standardisiertes Treiberkonzept auf Betriebssystemebene. FireDAC kann darüber MariaDB ansprechen, wenn ein passender ODBC-Treiber installiert ist. Das wirkt auf den ersten Blick „administrationsfreundlich“, weil ODBC in vielen Unternehmen ohnehin etabliert ist (z. B. für Reporting-Tools).

Üzemeltetési szempont: ODBC egyszerűsítheti a telepítést, ha Sie bereits ein standardisiertes Treiberpaket per Softwareverteilung ausrollen. Allerdings entstehen zusätzliche Abstraktionsschichten: Fehlermeldungen sind manchmal weniger präzise, und Treiber-Updates müssen besonders kontrolliert werden, weil sie auch andere Anwendungen beeinflussen können.

Döntési kritériumok vállalatok számára

• Rollout-Kontrolle: A natív könyvtár alkalmazásonként „mitliefern“ gyakran tisztább megoldás, mint rendszerwide ODBC-Änderungen.
• Change-Management: ODBC eignet sich, wenn Treiberversionen zentral gemanagt werden und gut getestet sind.
• Fehlerdiagnose: A natív Pfade sind häufig direkter zu debuggen (Handshake/TLS/Auth).
• Kompatibilität: Bei Auth-Plugins und TLS-Policies kann der jeweilige Treiber entscheidend sein.

In vielen stabilen Unternehmenssetups setzt man für produktive Desktop- oder Service-Anwendungen auf die native Library (gezielt versioniert und mit der Anwendung ausgeliefert) und nutzt ODBC eher dort, wo Dritttools angebunden werden.

Kapcsolati paraméterek pontos meghatározása: Host, Port, Timeoutok, Failover

Ein häufiger Fehler in gewachsenen Anwendungen ist „irgendwie verbundene“ Konfiguration. Für Betrieb und Wartung brauchen Sie eine klare, nachvollziehbare Definition der Verbindungsparameter – und zwar pro Umgebung (Entwicklung, Test, Produktion) ohne harte Einbettung in Programmdateien.

Fontos paraméterek üzemeltetési szempontból:

• Host/Port: Az alapértelmezett 3306, de szegmentált hálózatokban eltérő portok gyakoriak.
• Connect Timeout: véd a „beragadt“ kapcsolódási kísérletektől routing- vagy DNS-problémák esetén.
• Read/Write Timeout: megakadályozza, hogy hálózati problémák miatt egyes kérések blokkolják a folyamatot.
• Keepalive: hasznos hosszabb inaktív periódusoknál, különösen WAN/VPN-útvonalakon.
• Failover-Strategie: replikáció vagy cluster esetén definiálni kell, hogyan válthatnak át a kliensek (vagy szándékosan nem automatizálják azt).

Gyakorlati szabály: Timeoutok nem „Nice-to-have“, hanem az üzembiztonság részei. Hiányuk esetén egyes kliensek vagy szolgáltatások erőforrásokat köthetnek le és másodlagos hatásokat indíthatnak el (pl. megtelnek a thread-poolok, UI nem reagál, feladatok torlódnak).

TLS und Zertifikate: Verschlüsselung ist ein Betriebsprojekt, kein Haken

In modernen Umgebungen ist TLS (Transport Layer Security, also Verschlüsselung auf der Transportstrecke) nicht optional. Entscheidend ist, dass TLS nicht nur „aktiviert“, sondern korrekt validiert wird: Server-Zertifikat prüfen, CA-Kette kontrollieren, Hostname-Verifikation sicherstellen und veraltete Protokolle ausschließen.

Tipische Stolpersteine bei Delphi/FireDAC im Unternehmensbetrieb:

• Zertifikatspfad und Berechtigungen: A szolgáltatások gyakran dedikált fiókok alatt futnak; ott a CA-fájlok/tanúsítványtárak elérhetőknek kell lenniük.
• Hostname vs. Zertifikat-CN/SAN: Ha a kliensek alias-neveken csatlakoznak (DNS-CNAME, VIP), a tanúsítványnak fedeznie kell ezeket a neveket.

Az IT-felelősök számára fontos: határozza meg, ki telepíti a tanúsítványokat, hogyan működik a megújítás és hogyan felügyelik az érvényességet. A titkosítás nem csak alkalmazási kérdés, hanem érinti a PKI-folyamatokat (Public Key Infrastructure) és a változásablakokat.

Karakterkészletek, kollációk és „elromlott ékezetek”: Okok szisztematikus elkerülése

Egy klasszikus probléma adatbázis-migrációknál és új kapcsolódásoknál a hibás speciális karakterek vagy „furcsa“ rendezések. Az ok szinte soha nem az, hogy „Delphi nem tud UTF-8-at”, hanem a karakterkészlet-alapértelmezések, tábla/mező definíciók és a kliens-handshake keveréke.

Amire figyelni kell:

• Szerver-alapértelmezés vs. sémadefiníció: Ne hagyatkozzon globális alapértelmezésekre. Határozza meg a karakterkészletet és a kollációt kifejezetten az adatbázis- és táblaszinten.
• UTF-8-változat: MariaDB/MySQL környezetben az utf8mb4 a robusztus választás (teljes Unicode, beleértve a 4 bájtos karaktereket). A régebbi „utf8” nem fed le mindent.
• Kliens-handshake: Az illesztőprogramnak tudnia kell, milyen kódolásban küld és fogad. Ha a kliens és a szerver eltérően egyeztet, rejtett adathibák keletkeznek.
• Sorrendezés (Collation): A kolláció befolyásolja az összehasonlításokat és az ORDER BY működését. Többnyelvűség vagy vegyes adatok esetén tudatos döntés szükséges.

Az üzemeltetés szempontjából kevésbé a elméletileg „helyes” kolláció számít, mint a következetesség: egyszer meghatározni, dokumentálni, és migrációk során ellenőrző lekérdezésekkel validálni. Folyamatközeli vállalati alkalmazásokban a sorrendezés változásai gyakran csak későn tűnnek fel (pl. listákban, exportokban vagy duplikátum-kezelési logikában).

Hitelesítés és felhasználói jogosultságok: Minimális jogosultságok, egyértelmű szerepek

MariaDB különböző hitelesítési mechanizmusokat kínál (jelszó-alapú, részben plugin-alapú). Alkalmazások esetén döntő, hogy egy dedikált DB-bejelentkezést használjon, és a jogosultságokat szigorúan a szükséglethez igazítsa. „DBA-jogosultságok az alkalmazás számára” felesleges kockázat.

Ajánlott gyakorlat vállalati környezetben:

• Külön felhasználók alkalmazásonként/szolgáltatásonként (és szükség esetén bérlőnként/környezetenként).
• Least Privilege: csak SELECT/INSERT/UPDATE/DELETE a szükséges objektumokon, nincsenek globális jogosultságok.
• Nincs dinamikus DDL-jogosultság (CREATE/ALTER) a termelési alkalmazásokban, kivéve, ha ez egy kontrollált migrációs folyamat része.
• Jelszórotáció tervezett átállással (pl. rövid átmeneti időszakra párhuzamosan érvényes hozzáférések).

Ha az alkalmazás háttérfeladatokat futtat (importok, interfészek, kötegelt feldolgozás), gyakran érdemes ezekhez külön fiókokat használni. Ez javítja az auditálhatóságot és korlátozza a károkat kompromittált hozzáférési adatok esetén.

Tranzakciók, izoláció és zárolás: tegyük tervezhetővé ahelyett, hogy „az adatbázis néha lassú”

Sok Delphi-meglévő alkalmazásban az adatmódosítások történetileg alakultak ki: egyszeri frissítések tiszta tranzakciós határok nélkül, „optimista” feltételezések vagy túl széles zárolások. MariaDB tárolómotortól függően másként viselkedik; a gyakorlatban az InnoDB jellemző választás (tranzakciók, sor-szintű zárolás, összeomlás utáni helyreállítás).

IT- és projektfelelősök számára a következő pontok döntőek:

• Tranzakcióhatárok: Egy üzleti művelet (pl. megrendelés rögzítése) legyen egyértelműen definiált tranzakcióhoz kötve. Homályos határok nehezen reprodukálható köztes állapotokat eredményeznek.
• Izolációs szint: Meghatározza, mely „köztes állapotok” láthatók. Túl magas izoláció növelheti a zárolásokat és a várakozásokat, túl alacsony izoláció pedig szakmailag helytelen eredményekhez vezethet.
• Zárolások/Deadlockok: A deadlockok nem az „adatbázis hibái”, hanem a versengő hozzáférési útvonalak jelei. Fontos, hogy az alkalmazás észlelje őket, tisztán naplózza, és kontrollált módon újrapróbálkozzon (Retry) – természetesen korlátokkal.
• Hosszú tranzakciók: Nyitott tranzakciók UI-interakciók vagy hosszú folyamatok során gyakori oka a zárolási és teljesítményproblémáknak.

A gyakorlatban beválik: rövid tranzakciók, frissítések egyértelmű sorrendje (a deadlockok csökkentésére), és olyan naplózás, amely hiba esetén követhetővé teszi az érintett SQL-műveleteket és a kontextusadatokat, miközben nem naplóz érzékeny adatokat tiszta szövegként.

Teljesítmény: indexek, paraméterek, roundtrip-ek és tipikus FireDAC-csapdák

Ha a MariaDB-re történő átállás után „minden kicsit lassabbnak” tűnik, ritkán magával a MariaDB termékkel van a gond; általában a lekérdezések tervezése, az indexelés és a kliens viselkedésének kombinációja okozza. FireDAC sok beállítási lehetőséget kínál – a feladat az, hogy ezeket üzemeltethetően kontrolláljuk.

Indexek és a lekérdezési valóság ellenőrzése

Az adminisztráció számára döntő fontosságú, hogy a legfontosabb lekérdezéseket azonosítsák és Explain-tervek alapján értékeljék. A váratlan terhelés tipikus okai:

• hiányzó vagy hibás összetett indexek (többoszlopos indexek, amelyek illeszkednek a WHERE/ORDER BY használathoz)
• LIKE-keresések megfelelő stratégia nélkül (pl. prefix vs. teljes szöveg)
• függvények oszlopokon a WHERE-klauszulában (az index nem kerül használatra)
• nagy variancia a paraméterértékekben (a tervválasztás ingadozik)

Ez kevésbé „fejlesztői optimalizáció”, inkább üzemeltetési fegyelem: a legfontosabb lekérdezéseket rendszeresen ellenőrizni, a regressziókat kiadások után felügyelni, és az SQL-logikát az üzleti követelményekkel összevetni.

Roundtripek csökkentése és a Fetch-viselkedés tudatos kiválasztása

Roundtrip azt jelenti: egy Request/Response-ciklus az alkalmazás és az adatbázis között. Sok kis roundtrip a LAN-on gyakran észrevétlen, de VPN-en vagy nagy párhuzamosság esetén költséges. FireDAC blokkonként tud adatot lekérni (Fetch-opciók) és támogat batch/array műveleteket. Fontos, hogy ezeket az opciókat ne „globálisan” agresszívan állítsák be, hanem alkalmazásonként döntsenek (listák, részletes képernyők, exportok, interfészfeladatok).

Paraméterkötés a String-SQL helyett

A paraméterezett lekérdezések nemcsak az SQL-Injection ellen segítenek, hanem javítják a plan-cachinget és csökkentik az encoding-problémákat. Üzemeltetési szempontból ez kevesebb „különleges esetet”, kevesebb nehezen magyarázható hibát bizonyos karaktereknél, és nagyobb stabilitást jelent visszatérő lekérdezéseknél.

Kapcsolat-pooling és párhuzamosság: asztali kliens, szolgáltatás, terminálszerver

Vállalati környezetben a használati minta döntő: egyetlen asztali kliens más, mint 50 párhuzamos felhasználó terminálszerveren, vagy egy Windows-/Windows- und Linux-Services, amely a háttérben dolgozza fel a feladatokat. „Túl sok kapcsolat” nemcsak limitációkhoz vezet, hanem fölösleges terhelést okoz a kézfogások (handshakes) és a memória miatt.

Fontos szempontok:

• Folyamatonként vs. szálanként: FireDAC-kapcsolatok erőforrások; tervezze meg, hány párhuzamos DB-műveletre van valóban szükség.
• Pooling: Egy pool csökkenti a kapcsolódási overheadet, ugyanakkor gondos „rendbetételt” igényel (tranzakciók lezárása, munkamenet-beállítások visszaállítása).
• Munkamenet-állapot: Ha munkamenetenként változókat állít be (pl. SQL_MODE, időzóna), ezeknek a pool-környezetben konzisztensnek kell lenniük.
• Terminalserver: Sok felhasználó ugyanazt a szervert használja, de nem ugyanazt a folyamatot. Ez befolyásolja, hogyan skálázódik fel a kapcsolatszám.

Üzemeltetési szempontból legyen egyértelmű célérték: hány aktív kapcsolatra van elfogadható csúcsidőben, milyen limitációk vannak az adatbázis-oldalon, és hogyan viselkedik az alkalmazás terhelés alatt (backpressure a „mindent egyszerre” helyett).

Gyakorlati hibahelyzetek: mit kell korán észlelni

Sok probléma nem a fejlesztői teszten jelentkezik, hanem a hálózat, jogosultságok, frissítések és adatkészlet kölcsönhatásában. Tipikus hibakategóriák:

• „Can’t connect”: DNS, tűzfal, hibás port, hiányzó útvonalak, túl rövid csatlakozási timeoutok.
• TLS-Handshake meghiúsul: lejárt tanúsítványok, hibás CA, a hosztnév nem egyezik, a protokoll-politika túl szigorú/túl megengedő.
• „Access denied”: jogosultságok nincsenek összehangolva a hostmaszkokkal (felhasználó@hoszt), jelszórotáció összehangolt bevezetés nélkül.
• Kódolási problémák: az alapértelmezett karakterkészlet nem konzisztens, vegyes adatok régi importokból.
• Deadlockok/lock waits: hosszú tranzakciók, eltérő frissítési sorrendek, hiányzó indexek FK-oszlopokon.

Ajánlás: határozzon meg minden hibakategóriához egy diagnosztikai ellenőrzőlistát (mely logok, mely adatbázis-állapotok, mely hálózati vizsgálatok). Ez jelentősen csökkenti az MTTR-t (Mean Time to Repair), és megakadályozza, hogy vészhelyzetben „a ködben” keressen.

Migrációk és vegyes üzem: MySQL-ről vagy legacy rendszerekből MariaDB-re

Projektekben a MariaDB-csatlakozás gyakran modernizálási kontextusban jön létre: MySQL-verziók kikerültek a támogatás alól, egy adatbázisszervert konszolidálni kell, vagy egy alkalmazást leválasztanak egy legacy adat-hozzáférésből (pl. BDE). Technikailag ezek a lépések megvalósíthatók – a kockázatok a részletekben rejlenek.

Fontos pontok a biztonságos átmenethez:

• Adattípusok ellenőrzése: különösen dátum/idő, DECIMAL-skálák, szövegoszlopok, NULL-/alapértelmezett logika.
• SQL-dialektus és függvények: apró eltérések a függvényekben vagy a strict-mode beállításokban megváltoztathatják az üzleti logikát.
• Stored Procedures/Views: ha használatban vannak, a kompatibilitásnak és a deploy-folyamatnak egyértelműnek kell lennie.
• Időzónák: a szerver- és munkamenet-időzóna befolyásolja a TIMESTAMP/DATETIME viselkedését; auditok és interfészek szempontjából a konzisztencia kritikus.
• Cutover-terv: adatösszehangolás, fagyasztási időablak, rollback-opció és monitorozás az első napokban.

Különösen folyamatközeli szoftvermegoldásoknál a „Big Bang” ritkán szükséges. Gyakran egy lépcsőzetes megközelítés célszerű: először a driverek és konfigurációs képességek biztosítása, majd az adatszerkezet és a lekérdezések ellenőrzése, végül a modulok fokozatos átállítása. Ezeket a témákat jól lehet belső modernizációs kezdeményezésekkel összekapcsolni, például ha párhuzamosan fut egy Delphi Modernizáció vagy egy BDE-kiváltás.

Monitoring, naplózás és karbantartás: mit vár el az üzemeltetés és a revízió

Ha egy Delphi-alkalmazás produktív környezetben MariaDB-hez csatlakozik, az adatbázis-kapcsolat nem lehet „láthatatlan”. Az üzemeltetés és a megfelelőség szempontjából fontos a nyomon követhetőség és a minimális támadási felület.

Mit kell az adatbázis-oldalon nyomon követni

• Kapcsolatszámok és csúcsok: korrelálnak verzióváltásokkal, terminálszerver-terheléssel vagy feladatok időablakaival.
• Slow Query Log: megmutatja, hol vész el valós idő (nem csak CPU, hanem zárolások miatt is).
• Zárolási várakozási idők: utalások konkurens műveletekre és hiányzó indexekre.
• Replikációs állapot (ha használatban van): késések fontosak kiértékelések és failover szempontjából.

Mit kell az alkalmazásnak biztosítania

• Korrelációs azonosítók: hogy adatbázis-hibák egy szakmai folyamatra visszakövethetők legyenek.
• Technikai naplózás SQL-kontextussal (melyik használati eset, melyik lekérdezés‑osztály), de érzékeny adatok ne legyenek tiszta szövegben.
• Konfigurációs átláthatóság: melyik illesztőprogram-verzió, milyen TLS-policy, mely szervercím – támogatási esetekben döntő.

A cél nem „több napló”, hanem használható napló: gyorsan behatárolható, adatvédelmi szempontból megfelelõ és a másodszintű támogatás számára feldolgozható.

Biztonság és hardening: gyakorlati intézkedések, die in Delphi-Projekten oft fehlen

Egy stabil kapcsolódás azt is jelenti: nincsenek felesleges támadási felületek. A TLS és a minimális jogosultságok mellett a következő pontok játszanak szerepet:

• Secrets-Handling: jelszavak ne legyenek védtelenül tiszta szövegű konfigurációs fájlokban. In Windows-Umgebungen kann DPAPI/Protected Storage helfen; unter Linux sind RESTriktive Dateirechte und Secret-Stores üblich.
• SQL-Injection-Schutz: következetes paraméterezés, még keresőmezők és dinamikus szűrők esetén is.
• Patch-Prozess: illesztőprogramok/klienstárak a támadási felület részei. Verziókezelés és roll-out ugyanolyan fontos, mint a szerverfrissítések.
• Netzsegmentierung: az adatbázis-szerver ne legyen „mindenkinek” elérhető, hanem csak az alkalmazásszerverek/kliensek alhálózataiból.

Döntéshozók számára fontos: a biztonság kevésbé egyedi megoldásokból adódik, mint inkább egy ismételhető folyamatból (változtatások tesztelése, kontrollált bevezetés, folyamatos felügyelet).

Ellenőrzőlista: So wird die MariaDB-Anbindung mit FireDAC langfristig wartbar

A következő ellenőrzőlista szándékosan üzemeltetésközeli megfogalmazású és alkalmas projektátvétel vagy üzemeltetési dokumentáció alapjául:

1. Illesztőválasztás meghatározva (natív könyvtár vagy ODBC) verziókezelési és frissítési stratégiával.
2. Konfigurációk externalizálva (környezetek elkülönítve, hardcode-ok nélkül, követhető alapértelmezések).
3. TLS megfelelően megvalósítva (verifikáció aktív, tanúsítványlánc teljes, megújítási folyamat definiálva).
4. Karakterkódolási stratégia (utf8mb4, kollációk dokumentálva, migráció ellenőrizve).
5. DB-szerepek és jogosultságok (legkisebb jogosultság elve, külön fiókok, forgatás tervezhető).
6. Tranzakciótervezés (egyértelmű határok, rövid futásidők, deadlock-kezelés definiálva).
7. Monitoring/naplózás (lassú lekérdezések, lock-wait, korrelációs azonosítók, adatvédelmi megfelelés).
8. Terhelési és kapcsolódási modell (pooling, párhuzamosság, limitek, terminálszerver-/szolgáltatási scenáriók).

Összegzés: „Működik” nem elég – egy jó kapcsolódás üzemeltetési döntés

MariaDB megbízhatóan integrálható Delphi és FireDAC használatával, ha a csatlakozást a teljes architektúra részének tekintik: az illesztőprogram-választás, a TLS, a karakterkészletek, a jogosultságok, a tranzakciók és a monitoring összhangban kell legyenek. Azok, akik ezeket a szempontokat időben pontosan eldöntik és dokumentálják, jelentősen csökkentik az üzemeltetés későbbi meglepetéseit – különösen a már kiforrott, folyamathoz közeli vállalati alkalmazásoknál, ahol a stabilitás és a karbantarthatóság fontosabb a rövid távú megkerüléseknél.

Ha a MariaDB-csatlakozását modernizáció, egy BDE-kiváltás vagy az adathozzáférések konszolidálása keretében szeretné strukturálni, beszéljen velünk a feltételeiről és a legcélszerűbb migrációs útról:

A szakmai környezetben szintén fontos szerepet játszanak a FireDAC Mariadb és a Delphi Mariadb-kapcsolatok, amikor az integrációknak, az adatáramlásoknak és a további fejlesztéseknek tisztán együtt kell működniük.

Projektet vagy modernizációs tervet Net-Base közreműködésével beszélje meg.