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

Den, som vil tilslutte MariaDB med Delphi og BDE-udskiftning med native tilslutning, har som regel mere i sigte end blot en succesfuld forbindelse. I virksomhedsmiljøer er det især driftssikkerhed, entydig konfiguration, reproducerbare deployment-processer og en dataadgang, der forbliver stabil under belastning, der tæller. MariaDB bruges ofte som en omkostningseffektiv, lettilgængelig alternativ i MySQL-økosystemet – og Delphi-applikationer er i mange virksomheder modne, procesnære løsninger, som skal køre pålideligt og videreudvikles over år.

I dette indlæg handler det derfor ikke om framework-detaljer eller demo-code, men om de beslutninger, som IT-ledelse og administration faktisk berøres af: Hvilken driverstrategi er fornuftig (native client-libraries vs. ODBC), hvordan undgår I tegnsæts- og collation-problemer, hvordan planlægger I TLS korrekt, hvilke transaktions- og låseaspekter 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 over forretningssoftwarens levetid forbliver vedligeholdelses- og revisionsvenlig.

Tilslutning af MariaDB med Delphi og FireDAC i praksis

MariaDB stammer historisk fra MySQL og er på mange områder kompatibel, men ikke identisk. For driften betyder det: Mange værktøjer, koncepter og client-drivere opfører sig lignende, men der er forskelle i features, standardværdier, optimizer-adfærd og indimellem også i datatyper eller systemvariable. For Delphi/BDE-Ablosung mit nativer Anbindung er det især relevant i spørgsmålet om, hvilken drivervej der anvendes, og hvilke SQL-dialektforudsætninger applikationen bygger på.

FireDAC er datatilgangslaget i Delphi, som kan binde mange databaser ensartet. FireDAC kapsler forbindelsen, parametre, transaktioner og datasæt-adfærd. Vigtigt i virksomhedshverdagen: FireDAC er ikke bare „en driver“, men et lag, der afhængigt af databasen kan benytte forskellige drivermodi. For MariaDB fører det i praksis til to robuste spor: native MySQL/MariaDB-client-libraries eller ODBC.

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

Det vigtigste valg er, om I tilslutter FireDAC via en native client-library (fra MySQL/MariaDB-miljøet) eller via en ODBC-driver. Begge veje er teknisk valide, men de adskiller sig i deployment, opdateringsprocesser og fejlbilleder.

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

Ved native tilslutning benytter FireDAC en klientbibliotek, som skal være tilgængelig 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 versionshistorik og distributionskanaler.
• MariaDB Connector/C: ofte mere konsistent i forhold til MariaDB-servere, med egen release-cyklus.

Set fra driftssynspunkt: Native libraries leverer typisk den bedste ydeevne og den mest direkte fejldiagnose (handshake, TLS, autentificering). Prisen er en ekstra deployment-komponent: Den korrekte library-version skal være til stede på alle målsystemer og må ikke blive tilfældigt overskrevet af anden software.

ODBC (MariaDB ODBC Driver)

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

Driftsmæssigt: ODBC kan forenkle deployment, hvis I allerede distribuerer et standardiseret driverpakke via softwaredistribution. Til gengæld introducerer det ekstra abstraktionslag: fejloplysninger er nogle gange mindre præcise, og driveropdateringer skal kontrolleres særligt omhyggeligt, fordi de også kan påvirke andre applikationer.

Beslutningskriterier for Unternehmen

• Rollout-kontrol: At levere et native-bibliotek sammen med hver applikation er ofte renere end systemomfattende ODBC-ændringer.
• Change-management: ODBC er egnet, hvis driverversioner styres centralt og er veltestede.
• Fejldiagnose: Native forbindelsesveje er ofte lettere at debugge (Handshake/TLS/Auth).
• Kompatibilitet: Ved Auth-Plugins og TLS-politikker kan den konkrete driver være afgørende.

I mange stabile virksomhedsopsætninger anvender man til produktive desktop- eller serviceapplikationer det native-bibliotek (målrettet versioneret og leveret med applikationen) og bruger ODBC primært der, hvor tredjepartsværktøjer tilsluttes.

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

En hyppig fejl i voksede applikationer er en „på en eller anden måde forbundet“ konfiguration. Til drift og vedligehold kræves en klar, sporbar definition af forbindelsesparametrene – pr. miljø (udvikling, test, produktion) uden hård indlejring i programfiler.

Vigtige parametre set fra driftssynspunkt:

• Host/Port: Standard er 3306, men i segmenterede netværk er afvigende porte almindelige.
• Connect Timeout: beskytter mod fastlåste forbindelsesforsøg ved routing- eller DNS-problemer.
• Read/Write Timeout: forhindrer, at enkelte forespørgsler ved netværksproblemer blokerer processen.
• Keepalive: nyttigt ved længere idle-perioder, især over WAN/VPN-forbindelser.
• Failover-strategi: ved replikation/cluster bør I definere, hvordan klienter må skifte over (eller bevidst ikke automatisk).

Praksisregel: 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ølgeeffekter (f.eks. Thread-Pools bliver fyldte, UI reagerer ikke, jobs hober sig op).

TLS og certifikater: Kryptering er et driftsprojekt, ikke et flueben

I moderne miljøer er TLS (Transport Layer Security, altså kryptering på transportlaget) ikke valgfri. Det er afgørende, at TLS ikke blot er „aktiveret“, men korrekt valideret: verificer servercertifikat, kontroller CA-kæden, sikre hostname-verifikation og ekskluder forældede protokoller.

Typiske faldgruber ved Delphi/FireDAC i virksomhedsdriften:

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

For IT-ansvarlige er det vigtigt her: Fastlæg, hvem der ruller certifikater ud, hvordan renewal 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 „ødelagte Umlaute“: Årsager undgås systematisk

Et klassisk problem ved database-migrationer og nye tilslutninger er forkerte specialtegn eller „mærkelige“ sorteringer. Årsagen er næsten aldrig „Delphi kan ikke håndtere UTF-8“, men et mix af tegnsæts-defaults, tabel-/kolonnedefinitioner og client-handshake.

Hvad I skal være opmærksomme på:

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

I driften er det vigtigere med konsekvens end med den teoretisk „rigtige“ collation: Fastlæg det én gang, dokumentér det, og kontroller ved migrationer med testqueries. Især i procesnære virksomhedsapplikationer opdages ændringer i sortering sent (fx i lister, eksporter eller dubletlogik).

Autentificering og brugerrettigheder: Minimale rettigheder, klare roller

MariaDB tilbyder forskellige autentificeringsmekanismer (password-baseret, delvis pluginbaseret). For applikationer er det afgørende, at I bruger et dedikeret DB-login og tilpasser rettighederne strengt efter behov. „DBA-rettigheder for 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 del af en kontrolleret migrationsproces.
• Adgangskodsrotation med planlagt udskiftning (fx parallel gyldige adgangsdata i korte overgangsperioder).

Hvis applikationen kører baggrundsjob (importer, snitflader, batch-behandling), er det ofte fornuftigt også at bruge separate konti hertil. Det forbedrer audit-sporbarheden og begrænser skaden ved kompromitterede adgangsoplysninger.

Transaktioner, Isolation og Locking: Gør det planlægbart i stedet for „Databasen er nogle gange langsom“

I mange Delphi-bestående applikationer er dataændringer vokset historisk: enkeltstående updates uden klare transaktionsgrænser, „optimistiske“ antagelser eller for brede låse. MariaDB opfører sig forskelligt afhængigt af storage engine; i praksis er InnoDB som regel valgt (transaktioner, række-niveau-låse, gendannelse efter nedbrud).

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 vanskeligt reproducerbare mellemtillstande.
• Isolationsniveau: Bestemmer, hvilke „mellemtider“ der er synlige. For høj isolation kan øge locks og ventetider; for lav isolation kan det give fagligt forkerte resultater.
• Locking/Deadlocks: Deadlocks er ikke en „databasefejl“, men et tegn på konkurrerende adgangsveje. Det er vigtigt, at applikationen genkender dem, logger dem ordentligt og forsøger kontrolleret igen (Retry) – dog med begrænsninger.
• Lange transaktioner: Åbne transaktioner over UI-interaktioner eller lange processer er en hyppig årsag til lock- og performanceproblemer.

I praksis viser det sig effektivt: korte transaktioner, klar rækkefølge ved opdateringer (for at reducere deadlocks) og en logning, der i fejltilfælde gør de berørte SQL-operationer og kontekstdata rekonstruerbare, uden at protokollere følsomme data i klartekst.

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

Hvis det efter omlægningen til MariaDB virker som om „alt er en smule trægere“, skyldes det sjældent MariaDB som produkt, men en kombination af forespørgselsdesign, indeksering og klientadfærd. FireDAC tilbyder mange justeringsmuligheder – kunsten er at holde dem driftsmæssigt kontrollerbare.

Kontroller indekser og forespørgselsrealitet

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

• manglende eller forkerte sammensatte indekser (flerspaltede indekser svarende til WHERE/ORDER BY-brugen)
• LIKE-søgninger uden egnet strategi (f.eks. præfiks vs. fuldtekst)
• funktioner på kolonner i WHERE-klausuler (indeks bruges ikke)
• stor varians i parameterværdier (planvalget svinger)

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

Reducer roundtrips og vælg fetch-adfærd bevidst

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

Parameterbinding i stedet for String-SQL

Parameteriserede queries hjælper ikke kun mod SQL-injection, men forbedrer også plan-caching og reducerer kodningsproblemer. For driften betyder det: færre „særlige tilfælde“, færre svært forklarlige fejl ved bestemte tegn, og mere stabilitet ved tilbagevendende 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 et Windows-/Windows- og Linux-services, der i baggrunden behandler jobs. „For mange forbindelser“ fører ikke kun til grænser, men også til unødig belastning via handshakes og memory.

Vigtige overvejelser:

Fra driftsmæssigt synspunkt bør der være en klar målsætning: hvor mange aktive forbindelser i spidsbelastning der er acceptable, hvilke limits 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 opdage tidligt

Mange problemer optræder ikke ved udviklertest, men i samspillet mellem netværk, rettigheder, 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, hostnavn stemmer ikke, protokolpolitik for streng/for lempelig.
• „Access denied“: Rettigheder ikke afstemt med hostmasker (Bruger@Host), passwordrotation uden koordinerede udrulninger.
• Encoding-problemer: standardtegnsæt ikke konsistent, blandede data fra gamle importer.
• Deadlocks/Lock waits: lange transaktioner, forskellige opdateringsrækkefølger, manglende indeks 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 et alvorligt tilfælde „leder i tågen“.

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

I projekter opstår MariaDB-tilslutning ofte i forbindelse med modernisering: MySQL-versioner er ude af support, en databaseserver skal konsolideres, eller en applikation løsrives fra en legacy-datadgang (f.eks. BDE). Teknisk er disse skridt gennemførlige – risiciene ligger i detaljerne.

Vigtige punkter for en sikker vej:

• Tjek 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 afklaret.
• Tidszoner: server- og session-tidszone påvirker TIMESTAMP/DATETIME-adfærd; for audits og interfaces er konsistens central.
• Cutover-plan: dataafstemning, freeze-tidsvindue, rollback-mulighed og overvågning i de første dage.

Især for procesnære softwareløsninger er en „Big Bang“ sjældent nødvendig. Ofte er en trinvis tilgang fornuftig: først etablere driver- og konfigurationsunderstøttelse, derefter gennemgå datamodel og queries, og så migrere moduler trinvist. Indhold hertil kan godt kobles til interne moderniseringstemaer, for eksempel når en Delphi Modernisering eller en BDE-Abløsning kører parallelt.

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

Hvis en Delphi-applikation i produktiv drift tilgår MariaDB, bør databaseforbindelsen ikke være „usynlig“. For administration og compliance er sporbarhed og en minimal angrebsflade vigtige.

Hvad I bør overvåge på databasesiden

• Antal forbindelser og spidser: korrelerer med release-skift, terminalserver-belastning eller job-tidsvinduer.
• Slow Query Log: viser, hvor reel tid går tabt (ikke kun CPU, også låsninger).
• Lås-ventetider: indikationer på konkurrerende operationer og manglende indekser.
• Replikationsstatus (hvis anvendt): forsinkelser er relevante for analyser og failover.

Hvad applikationen bør levere

• Korrelations-ID’er: så DB-fejl kan knyttes til et forretningsmæssigt forløb.
• Teknisk logging med SQL-kontekst (hvilket Use-Case, hvilken Query-Klasse), men uden følsomme oplysninger i klartekst.
• Konfigurationsgennemsigtighed: hvilken Treiberversion, hvilken TLS-Policy, hvilken Serveradresse – afgørende i supportsager.

Målet er ikke „mere log“, men brugbar logning: hurtigt afgrænselig, i overensstemmelse med databeskyttelsesreglerne og anvendelig for 2nd-Level-Support.

Sikkerhed og Hardening: Praktiske foranstaltninger, die in Delphi-Projekten oft fehlen

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

• Secrets-Handling: 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-Schutz: konsekvent parameterisering, også for søgemasker og dynamiske filtre.
• Patch-Prozess: drivere/Client-Libraries er en del af angrebsfladen. Versionering og rollout er lige så vigtige som server-patches.
• Netzsegmentierung: DB-servere må ikke være „for alt“ tilgængelige, men kun fra applikationsserveres/klienters subnet.

For beslutningstagere er det her relevant: sikkerhed opstår mindre gennem enkeltstående løsninger og mere gennem en gentagelig proces (ændringer teste, kontrolleret udrulle, overvåge).

Checkliste: So wird die MariaDB-Anbindung mit FireDAC langfristig wartbar

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

1. Valgt driverløsning (native Library eller ODBC) inkl. versions- og opdateringsstrategi.
2. Konfiguration eksternt håndteret (adskilte miljøer, ingen hardcodes, efterprøvelige defaults).
3. TLS korrekt implementeret (verifikation aktiv, certifikatkæde komplet, renewal-proces defineret).
4. Tegnsætningsstrategi (utf8mb4, Collations dokumenteret, migration afprøvet).
5. DB-roller og rettigheder (Least Privilege, adskilte accounts, rotation planbar).
6. Transaktionsdesign (klare grænser, korte varigheder, Deadlock-Handling defineret).
7. Monitoring/Logging (Slow Queries, Lock-Wait, Korrelations-ID’er, i overensstemmelse med databeskyttelsesreglerne).
8. Belastnings- og forbindelsesmodel (Pooling, Parallelität, 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. Dem, der træffer og dokumenterer disse punkter tidligt og korrekt, reducerer markant senere driftsmæssige overraskelser – især i etablerede, procesnære virksomhedsapplikationer, hvor stabilitet og vedligeholdelse er vigtigere end kortsigtede workarounds.

Hvis De ønsker at strukturere Deres MariaDB-tilslutning i forbindelse med en modernisering, en BDE-afvikling eller en konsolidering af dataadgangene, så tal med os om Deres rammebetingelser og den mest hensigtsmæssige migrationsvej:

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

Drøft projekt eller moderniseringsprojekt med Net-Base.