Wann Access reicht

Access ist schnell – wenn die Datenmenge klein ist und die Daten lokal liegen.
Ich arbeite damit bis ca. 100.000-200.000 Datensätze pro Tabelle.
Lokal, mit Indexen, ohne JOIN-Orgie – alles kein Problem.
Aber es gibt harte Grenzen:

• 2 GB pro .ACCDB
• 255 gleichzeitige Benutzer (theoretisch, praktisch 5-10)
• keine serverseitige Verarbeitung
• schwache Mehrbenutzerfähigkeit über Netzwerkfreigabe

Erste Anzeichen von „es wird eng“

• #DELETED in Formularen bei gleichzeitiger Bearbeitung
• Sekundenlange Ladezeiten bei einfachen Abfragen
• Locks und Abstürze bei Schreibzugriffen
• ODBC-Verbindungen werden langsam oder instabil
• Tabellenlinks werden inkonsistent oder fehlerhaft

Dann solltest Du nachdenken: Wie geht’s weiter?

Migrationsstrategie: Hybrid zuerst, dann Server

Ich mache in der Regel so:

1. Daten auslagern (nach MySQL/MariaDB)
2. Frontend bleibt Access
3. Schrittweise mehr Logik nach MySQL verschieben

Damit bleiben die Benutzeroberflächen vertraut.
Aber die Daten leben dort, wo sie performen.

Setup: MySQL als Backend für Access

1. Installiere MySQL ODBC 8.0 Unicode Driver
2. Richte eine System-DSN ein, z. B. MyKMUBackend
3. In Access: Externe Daten → ODBC-Datenbank → Verknüpfen

Ab dann kannst Du wie mit normalen Tabellen arbeiten – aber die Daten liegen auf dem Server.

Jet-SQL vs. MySQL: Was nicht geht

Access mag z. B. keine LIMIT-Klauseln.
Und MySQL kennt kein FIRST() oder TOP n.

Beispiel: Statt

SELECT TOP 10 * FROM tblKunden ORDER BY Anmeldedatum DESC

nimm:

SELECT * FROM tblKunden ORDER BY Anmeldedatum DESC

und filtere per Access-Formular oder VBA.

Wenn Du direkt auf MySQL-Views arbeitest, plane ein:

• PRIMARY KEY ist Pflicht für schreibbare Views
• GROUP_CONCAT() kann Ärger machen
• Jet-SQL ist langsamer bei komplexen Joins über ODBC

Serverseitige Views und Prozeduren

Hier gewinnt MySQL. Ich lagere teure Queries aus.

Beispiel: Artikel mit Bestand und letztem Preis

CREATE VIEW v_artikel_schnell AS
SELECT a.artikel_nr, a.bezeichnung, l.bestand, p.preis
FROM artikel a
LEFT JOIN lager l ON l.artikel_id = a.id
LEFT JOIN (
    SELECT artikel_id, MAX(preis) AS preis
    FROM preise
    GROUP BY artikel_id
) p ON p.artikel_id = a.id;

Diese View nutze ich dann in Access wie eine normale Tabelle.
Zugriffe sind deutlich schneller als in VBA geschachtelte Recordsets.

Trigger und Business-Logik auf Datenbankseite

Auch das ist ein Punkt: Access kann keine Trigger.
Wenn sich z. B. bei einem Lagerabgang automatisch ein Log-Eintrag bilden soll:

CREATE TRIGGER log_lagerabgang
AFTER UPDATE ON lager
FOR EACH ROW
BEGIN
    IF NEW.bestand < OLD.bestand THEN
        INSERT INTO lager_log (artikel_id, menge, datum)
        VALUES (NEW.artikel_id, OLD.bestand - NEW.bestand, NOW());
    END IF;
END;

Das entlastet das Frontend und reduziert Fehlerquellen.

Export großer Datenmengen

Access ist limitiert bei Excel-Exporten, CSVs oder XMLs ab 50.000 Zeilen.
Ich gehe dann über MySQL-Dumps, serverseitige Export-Prozeduren oder spezialisierten ETL mit Python.

Oder per SQL direkt in Dateien:

SELECT * INTO OUTFILE '/var/lib/mysql-files/export.csv'
FIELDS TERMINATED BY ';' OPTIONALLY ENCLOSED BY '"'
FROM artikel;

Wichtig: MySQL muss dafür Schreibrechte im Exportpfad haben.

Backup und Replikation

Access kann keine inkrementellen Backups.
MySQL bietet Snapshots, Replikation, Point-in-Time-Recovery.

Ab einer gewissen Datenmenge will der Kunde das.
Und Du willst es auch, spätestens nach dem ersten Datenverlust.

Mein Praxisgrenzwert

Bereich	Access gut geeignet bis
Artikelstammdaten	10.000
Kundenbewegungen	100.000
Bestellpositionen	250.000
Dateianhänge	Nicht empfohlen
API-Protokolle	max. 50.000 (dann rot)

Danach übergebe ich an MySQL. Meist MariaDB auf Linux, mit täglichem Dump und SSH-Zugriff.

Mein Fazit, mal abseits des SQL Servers

Access bremst nicht plötzlich.
Es fängt leise an.
Mit kleinen Hängern, defekten Joins, falschen Ergebnissen.
Wenn Du’s merkst: raus mit den Daten.
Und rein mit MySQL – Schritt für Schritt.