Tilslutning af MariaDB med Delphi og FireDAC: Arkitektur, drivervalg og drift uden overraskelser

Den, der vil tilslutte MariaDB med Delphi og BDE-udskiftning med native tilslutning, har som regel mere i fokus end “kun” en succesfuld forbindelse. I produktionsmiljøer er det især driftssikkerhed, entydig konfiguration, reproducerbare deployments og en datatilgang, der forbliver stabil under belastning, der tæller. MariaDB anvendes ofte som en omkostningseffektiv, let-administrerbar alternativ i MySQL-økosystemet – og Delphi-applikationer er i mange virksomheder modne, procesnære løsninger, der skal køre pålideligt og videreudvikles over år.

I dette indlæg handler det derfor ikke om framework-detaljer eller demo-kode, men om de beslutninger, der reelt vedrører IT-ledelse og drift: Hvilken driverstrategi er fornuftig (native client-libraries vs. ODBC), hvordan undgår man tegnsæts- og collation-problemer, hvordan planlægges TLS korrekt, hvilke transaktions- og locking-aspekter er relevante i MariaDB, og hvordan holdes overvågning, opdateringer og fejlsøgning håndterbare i dagligdagen. Målet er en tilslutning, der ikke bare “virker”, men som forbliver vedligeholdelses- og revisionsvenlig gennem Business-softwarens levetid.

Tilslutning af MariaDB med Delphi og FireDAC i praksis

MariaDB udspringer historisk af MySQL og er på mange områder kompatibel, men ikke identisk. I drift betyder det: Mange værktøjer, koncepter og klientdrivere fungerer på lignende vis, men der er forskelle i features, standardværdier, optimizer-adfærd og delvist også i datatyper eller systemvariabler. For Delphi/BDE-Ablosung mit nativer Anbindung er det især relevant i spørgsmålet om, hvilken driversti der benyttes, og hvilke SQL-dialektantagelser der ligger i applikationen.

FireDAC er dataadgangslaget i Delphi, som kan forbinde mange databaser ensartet. FireDAC kapsler forbindelse, parametre, transaktioner og dataset-adfærd. Vigtigt i virksomhedsdrift: FireDAC er ikke bare “en driver”, men et lag, der afhængig af database kan anvende forskellige drivermodi. For MariaDB fører det i praksis til to robuste veje: native MySQL/MariaDB-client-libraries eller ODBC.

Driverstrategi: Native Client-Library vs. ODBC – hvad er bedst i drift?

Den vigtigste beslutning er, om FireDAC skal tilsluttes via et native client-bibliotek (fra MySQL/MariaDB-økosystemet) eller via en ODBC-driver. Begge tilgange er teknisk valide, men de adskiller sig i deployment, opdateringsprocesser og i typiske fejlscenarier.

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

Ved native tilslutning arbejder FireDAC med et client-bibliotek, der skal være tilgængeligt ved runtime (typisk som en DLL under Windows eller som en shared library under Linux). I praksis møder man to varianter:

• MySQL-Client-Library: udbredt, men afhængig af versioner og distributionsveje.
• MariaDB Connector/C: ofte mere konsistent for MariaDB-servere, med egen udgivelsescyklus.

Driftsmæssigt: Native biblioteker leverer typisk den bedste performance og den mest direkte fejlanalyse (handshake, TLS, godkendelse). Prisen er en ekstra deployment-komponent: Den korrekte biblioteksversion skal være til stede på alle målsystemer og må ikke utilsigtet blive overskrevet af anden software.

ODBC (MariaDB ODBC Driver)

ODBC (Open Database Connectivity) er et standardiseret driverkoncept på operativsystemniveau. FireDAC kan derigennem tale med MariaDB, hvis en passende ODBC-driver er installeret. Det fremstår ved første øjekast „administrationsvenligt“, fordi ODBC i mange virksomheder i forvejen er etableret (f.eks. til reporting-værktøjer).

Driftsperspektiv: ODBC kan forenkle deployment, hvis I allerede ruller et standardiseret driverpakke ud via softwaredistribution. Til gengæld opstår der yderligere abstraktionslag: fejlmeddelelser er nogle gange mindre præcise, og driveropdateringer skal kontrolleres særligt, fordi de også kan påvirke andre applikationer.

Beslutningskriterier for virksomheder

• Rollout-kontrol: Et native-bibliotek pr. applikation, der medleveres, er ofte renere end systemomfattende ODBC-ændringer.
• Change-Management: ODBC er egnet, hvis driverversioner administreres centralt og er grundigt testet.
• Fejldiagnose: Native veje er ofte mere direkte at debugge (Handshake/TLS/Auth).
• Kompatibilitet: Ved Auth-plugins og TLS-politikker kan den konkrete driver være afgørende.

I mange stabile virksomhedsmiljøer anvender man til produktive desktop- eller serviceapplikationer det native bibliotek (målrettet versionsstyret og leveret med applikationen) og bruger ODBC snarere dér, hvor tredjepartsværktøjer tilsluttes.

Definér forbindelsesparametre tydeligt: Host, Port, Timeouts, Failover

En hyppig fejl i voksede applikationer er en „på en eller anden måde forbundet“ konfiguration. Til drift og vedligehold har I brug for en klar, efterprøvbar definition af forbindelsesparametre – og det per miljø (udvikling, test, produktion) uden hård indlejring i programfiler.

Vigtige parametre fra driftsperspektiv:

• Host/Port: Standard er 3306, men i segmenterede netværk er afvigende porte almindelige.
• Connect Timeout: beskytter mod ‚hangende‘ forbindelsesopbygninger ved routing- eller DNS-problemer.
• Read/Write Timeout: forhindrer, at enkelte requests ved netværksproblemer blokerer processen.
• Keepalive: fornuftigt ved længere idle-faser, særligt på WAN-/VPN-forbindelser.
• Failover-strategi: ved replikation/cluster bør I definere, hvordan klienter må skifte (eller bevidst ikke automatisk).

Praktisk regel: Timeouts er ikke ’nice-to-have‘, men en del af driftssikkerheden. Uden klare timeouts kan enkelte klienter eller services binde ressourcer og udløse følgevirkninger (fx thread-pools fyldes, UI reagerer ikke, jobs hober sig op).

TLS og certifikater: Kryptering er et driftprojekt, ikke en afkrydsning

I moderne miljøer er TLS (Transport Layer Security, altså kryptering på transportlaget) ikke valgfrit. Det afgørende er, at TLS ikke blot „aktiveres“, men korrekt valideres: tjekke servercertifikat, kontrollere CA-kæde, sikre hostname-verifikation og udelukke forældede protokoller.

Typiske faldgruber ved Delphi/FireDAC i virksomhedsdriften:

• Sti til certifikater og rettigheder: Services kører ofte under dedikerede konti; der skal CA-filer/certifikatstores være tilgængelige for disse.
• Hostname vs. certifikat-CN/SAN: Hvis klienter forbinder via alias-navne (DNS-CNAME, VIP), skal certifikatet dække disse navne.

For IT-ansvarlige er det vigtigt her: Fastlæg, hvem der udruller certifikater, hvordan fornyelse fungerer og hvordan I overvåger gyldigheden. Kryptering er ikke kun et applikationsanliggende, men vedrører PKI-processer (Public Key Infrastructure) og ændringsvinduer.

Tegnsæt, Collations og „Umlaute kaputt“: Årsager undgås systematisk

En klassiker ved databasemigrationer og nye integrationer er forkerte specialtegn eller „mærkelige“ sorteringer. Årsagen er næsten aldrig „Delphi kan ikke håndtere UTF-8“, men en blanding af tegnsæts-defaults, tabel-/kolonnedefinitioner og klient-handshake.

Hvad I bør være opmærksomme på:

• Server-Default vs. Skema-Definition: Stol ikke på globale defaults. Definér tegnsæt og collation eksplicit på database- og tabelniveau.
• UTF-8-Variante: I MariaDB/MySQL-miljøet er utf8mb4 det robuste valg (fuldt Unicode inkl. 4-byte-tegn). Det ældre „utf8“ dækker ikke alt.
• Client-Handshake: Driveren skal vide, hvilket tegnsæt den sender/modtager i. Hvis klient og server aftaler forskelligt, opstår der stille datafejl.
• Sortering (Collation): Collation påvirker sammenligninger og ORDER BY. Ved flersprogethed eller blandede data kræves en bevidst beslutning.

Til drift betyder det mindre, hvilken teoretisk „korrekte“ collation man vælger, end at være konsekvent: Fastlæg det én gang, dokumentér det, og kontroller ved migrationer med test-queries. Især i procesnære virksomhedsapplikationer opdages ændringer i sortering ofte først sent (f.eks. i lister, eksporter eller dubletlogik).

Autentificering og brugerrettigheder: Minimale rettigheder, klare roller

MariaDB tilbyder forskellige autentificeringsmekanismer (adgangskodebaseret, delvist plugin-baseret). For applikationer er det afgørende, at I bruger et dedikeret DB-login og tilpasser rettigheder strengt efter behov. „DBA-rettigheder til applikationen“ er en unødvendig risiko.

Anbefalet praksis i virksomhedsmiljøer:

• Separate brugere pr. applikation/service (og eventuelt pr. lejer/omgivelser).
• Least Privilege: kun SELECT/INSERT/UPDATE/DELETE på nødvendige objekter, ingen globale rettigheder.
• Ingen dynamiske DDL-rettigheder (CREATE/ALTER) i produktionsapplikationer, medmindre det er en del af en kontrolleret migrationsproces.
• Adgangskoderotation med planlagt omlægning (f.eks. parallelt gyldige adgangsoplysninger i korte overgangsperioder).

Hvis applikationen kører baggrundsjobs (importer, grænseflader, batch-behandling), er det ofte fornuftigt også at anvende separate konti til dette. Det forbedrer auditérbarhed og begrænser skaden ved kompromitterede legitimationsoplysninger.

Transaktioner, Isolation og Låsning: planlæg i stedet for „databasen er nogle gange langsom“

I mange Delphi-bestandsapplikationer er dataændringer vokset historisk: enkelte opdateringer uden klare transaktionsgrænser, „optimistiske“ antagelser eller for brede låse. MariaDB opfører sig afhængigt af storage engine forskelligt; i praksis er InnoDB som regel standard (transaktioner, row-level-locks, crash-recovery).

For IT- og projektansvarlige er følgende punkter afgørende:

• Transaktionsgrænser: En faglig operation (f.eks. bogføring af en ordre) bør have en defineret transaktion. Uklare grænser skaber svært reproducerbare mellemtilstande.
• Isolationsniveau: Bestemmer, hvilke „mellemtilstande“ der er synlige. For højt isolationsniveau kan øge låsning og ventetider, for lavt isolationsniveau kan give fagligt forkerte resultater.
• Låsning/Deadlocks: Deadlocks er ikke en „bug i databasen“, men et tegn på konkurrerende adgangsveje. Det vigtige er, at applikationen genkender dem, logger dem rent og kontrolleret og forsøger genkørsel (Retry) – dog med grænser.
• Lange transaktioner: Åbne transaktioner over UI-interaktioner eller lange processer er en hyppig årsag til låse- og performanceproblemer.

I praksis er det bevist: korte transaktioner, klar rækkefølge ved opdateringer (for at reducere deadlocks), og et logging, der i fejltilfælde gør de berørte SQL-operationer og kontekstdata efterfølgeligt, uden at logge følsomme data i klartekst.

Performance: Indekser, parametre, roundtrips og typiske FireDAC-fælder

Hvis det efter overgangen til MariaDB „føles en smule langsommere“, skyldes det sjældent MariaDB som produkt, men en kombination af query-design, indeksering og klientadfærd. FireDAC tilbyder mange indstillingsmuligheder – kunsten er at holde dem operationelt kontrollerbare.

Gennemgå indekser og forespørgselsadfærd

For administrationen er det afgørende at identificere de vigtigste forespørgsler og vurdere dem med Explain-planer. Typiske årsager til uventet belastning:

• manglende eller forkerte sammensatte indekser (flerspaltede indekser tilpasset WHERE/ORDER BY-brug)
• LIKE-søgninger uden en egnet strategi (fx præfiks vs. fuldtekst)
• funktioner på kolonner i WHERE-klausuler (indekset bruges ikke)
• stor variation i parameterværdier (planvalget svinger)

Det er mindre „udvikleroptimering“ end driftsdisciplin: gennemgå top-queries regelmæssigt, kontroller regressioner efter releases, og afstem SQL-logikken med faglige krav.

Reducér roundtrips og vælg fetch-adfærd bevidst

Roundtrip betyder: en request/response-cyklus mellem applikation og database. Mange små roundtrips er over LAN ofte uproblematiske, men over VPN eller ved høj parallelitet dyre. FireDAC kan hente data blokvis (Fetch-optioner) og tilbyder batch-/array-operationer. Vigtigt er, at I ikke sætter disse optioner aggressivt „globalt“, men beslutter per anvendelsestilfælde (lister, detaljevinduer, eksport, integrationsjob).

Parameterbinding i stedet for String-SQL

Parametriserede queries hjælper ikke kun mod SQL-Injection, men forbedrer også plan-caching og reducerer kodningsproblemer. For driften betyder det: færre „særtilfælde“, færre vanskeligt forklarlige fejl ved bestemte tegn, og større stabilitet ved gentagne forespørgsler.

Connection Pooling og parallelitet: Desktop, Service, Terminalserver

I virksomhedsmiljøer er brugsmønsteret afgørende: En enkelt desktop-klient er noget andet end 50 parallelle brugere på en terminalserver eller en Windows-/Windows- und Linux-Services, der kører baggrundsjobs. „For mange forbindelser“ fører ikke kun til grænser, men også til unødvendig belastning gennem handshakes og hukommelsesforbrug.

Vigtige overvejelser:

• Per proces vs. per tråd: FireDAC-forbindelser er ressourcer; planlæg, hvor mange parallelle DB-operationer der reelt er brug for.
• Pooling: En pool reducerer forbindelses-overhead, men kræver ordentlig „oprydning“ (afslutte transaktioner, nulstille sessionindstillinger).
• Sessions-tilstand: Hvis I sætter variabler per session (f.eks. SQL_MODE, tidszone), skal disse være konsistente i pool-konteksten.
• Terminalserver: Mange brugere deler samme server, men ikke samme proces. Det påvirker, hvordan antallet af forbindelser skalerer op.

Fra driftssynspunkt bør der være et klart mål: hvor mange aktive forbindelser der er acceptable i spidsbelastning, hvilke grænser der gælder på DB-siden, og hvordan applikationen opfører sig under belastning (Backpressure i stedet for „alt på én gang“).

Fejlscenarier fra praksis: Hvad I bør fange tidligt

Mange problemer optræder ikke i udviklertesten, men i samspillet mellem netværk, adgangsrettigheder, opdateringer og datamængde. Typiske fejlklasser:

• „Can’t connect“: DNS, Firewall, forkert port, manglende ruter, for korte Connect-Timeouts.
• TLS-Handshake mislykkes: udløbne certifikater, forkert CA, værtsnavn passer ikke, protokolpolitik for streng/for lempelig.
• „Access denied“: Rettigheder ikke afstemt med hostmasker (Bruger@Host), kodeordsrotation uden koordinerede udrulninger.
• Encoding-problemer: standard-tegnsæt ikke konsistent, blandede data fra ældre importer.
• Deadlocks/Lock waits: lange transaktioner, forskellige opdateringsrækkefølger, manglende indekser på FK-kolonner.

Anbefaling: Definér for hver fejlklasse en diagnose-tjekliste (hvilke logs, hvilke DB-statusværdier, hvilke netværkskontroller). Det reducerer MTTR (Mean Time to Repair) markant, uden at I i alvorlige tilfælde behøver at lede „i tågen“.

Migrationer og blandet drift: Fra MySQL eller legacy-systemer til MariaDB

I projekter opstår MariaDB-tilslutning ofte i forbindelse med en modernisering: MySQL-versioner er uden for support, en databaseserver skal konsolideres, eller en applikation udløses fra en Legacy-Datentzugriff (z. B. BDE). Teknisk er disse skridt gennemførlige – risiciene ligger i detaljerne.

Vigtige punkter for en sikker overgang:

• Kontroller datatyper: især dato/tid, DECIMAL-skalaer, tekstkolonner, NULL-/default-logik.
• SQL-dialekt og funktioner: små forskelle i funktioner eller Strict-Mode-indstillinger kan ændre forretningslogikken.
• Stored Procedures/Views: hvis de bruges, skal kompatibilitet og deploymentsproces være klar.
• Tidszoner: server- og sessiontidszone påvirker TIMESTAMP/DATETIME-adfærd; for audits og interfaces er konsistens central.
• Cutover-plan: data-synkronisering, freeze-vindue, rollback-mulighed og overvågning i de første dage.

Særligt for procesnære softwareløsninger er et „Big Bang“ sjældent nødvendigt. Ofte er en trinvis tilgang mere fornuftig: først etablere driver- og konfigurationskapabilitet, derefter gennemgå datamodel og queries, og så gradvist migrere moduler. Indhold i den forbindelse kan passe godt sammen med interne moderniseringstiltag, for eksempel når en Delphi Modernisering eller en BDE-udskiftning parallelt kører.

Overvågning, logning og vedligeholdelse: Hvad drift og revision forventer

Når en Delphi-applikation kører i produktion og tilgår MariaDB, bør databaseforbindelsen ikke være ‚usynlig‘. For administration og compliance er efterprøvbarhed og en minimal angrebsflade vigtige.

Hvad I bør holde øje med på databasesiden

• Antal forbindelser og toppe: korrelerer med releaseskift, terminalserver-belastning eller job-tidsvinduer.
• Slow Query Log: viser, hvor reel tid går tabt (ikke kun CPU, også låse).
• Ventetider på låse: indikationer på konkurrerende operationer og manglende indekser.
• Replikationsstatus (hvis anvendt): forsinkelser er relevante for rapportering og failover.

Hvad applikationen bør levere

• Korrelations-IDs: så DB-fejl kan knyttes til en forretningsproces.
• Teknisk logning med SQL-kontekst (hvilket use-case, hvilken query-klasse), men uden følsomme data i klartekst.
• Konfigurationsgennemsigtighed: hvilken driverversion, hvilken TLS-Policy, hvilken serveradresse – afgørende i supportsager.

Målet er ikke „mere log“, men brugbar log: hurtigt at afgrænse, i overensstemmelse med databeskyttelsesregler og anvendelig for 2nd-level-support.

Sikkerhed og hardening: Praktiske foranstaltninger, som ofte mangler i Delphi-projekter

En stabil forbindelse betyder også: ingen unødvendige angrebsflader. Ud over TLS og minimale rettigheder spiller følgende punkter en rolle:

• Secrets-håndtering: adgangskoder må ikke ligge i klartekst i konfigurationsfiler uden beskyttelse. I Windows-miljøer kan DPAPI/Protected Storage hjælpe; under Linux er RESTriktive filrettigheder og Secret-Stores almindelige.
• SQL-injection-beskyttelse: konsekvent parameterisere, også i søgefelter og dynamiske filtre.
• Patch-proces: drivere/klientbiblioteker er en del af angrebsfladen. Versionering og rollout er lige så vigtige som server-patches.
• Netværkssegmentering: DB-servere må ikke være „tilgængelige for alt“, men kun fra applikationsservernes/clients‘ subnet.

For beslutningstagere er det relevant: Sikkerhed skabes mindre af enkeltstående løsninger og mere af en gentagelig proces (ændringer teste, kontrolleret udrulning, overvågning).

Tjekliste: Sådan bliver MariaDB-forbindelsen med FireDAC vedligeholdelsesvenlig på lang sigt

Følgende tjekliste er bevidst formuleret med driftsperspektiv og egner sig som grundlag for projektaccept eller driftsdokumentation:

1. Valg af driver (native Library eller ODBC) inkl. strategi for versionering og opdatering.
2. Konfiguration externaliseret (adskilte miljøer, ingen hardcodes, gennemsigtige standardværdier).
3. TLS korrekt implementeret (verifikation aktiv, certifikatkæde komplet, fornyelsesproces defineret).
4. Tegnsætningsstrategi (utf8mb4, collations dokumenteret, migration verificeret).
5. DB-roller og rettigheder (least privilege, adskilte konti, plan for rotation).
6. Transaktionsdesign (klare grænser, korte varigheder, deadlock-håndtering defineret).
7. Monitoring/Logging (Slow Queries, Lock-Wait, Korrelations-IDs, i overensstemmelse med databeskyttelse).
8. Belastnings- og forbindelsesmodel (pooling, parallelitet, limits, terminalserver-/service-scenarier).

Konklusion: „Virker“ er ikke nok – en god forbindelse er en driftsbeslutning

MariaDB kan integreres pålideligt med Delphi og FireDAC, når tilslutningen betragtes som en del af den samlede arkitektur: drivervalg, TLS, tegnsæt, rettigheder, transaktioner og overvågning skal passe sammen. Den, der træffer og dokumenterer disse beslutninger tidligt og præcist, reducerer senere driftsmæssige overraskelser markant – især i etablerede, procesnære virksomhedsapplikationer, hvor stabilitet og vedligeholdelse er vigtigere end kortsigtede nødløsninger.

Hvis I vil strukturere jeres MariaDB-tilslutning i forbindelse med en modernisering, en BDE-udskiftning eller en konsolidering af dataadgangene, så tal med os om jeres rammebetingelser og den mest hensigtsmæssige migrationsvej:

I det faglige miljø spiller også FireDAC Mariadb og Delphi Mariadb-forbindelser en vigtig rolle, når integrationer, dataflows og videreudvikling skal fungere sammen.

Drøft projekt eller moderniseringsforløb med Net-Base.