Leistung
Access VBA
Access ist nicht tot. In vielen Mittelständlern und Behörden trägt es nach 15-20 Jahren immer noch Geschäftsprozesse, die niemand wegwerfen kann oder will. Ich übernehme diese Bestände, stabilisiere sie, dokumentiere sie und migriere sie schrittweise auf SQL Server, wenn das wirtschaftlich passt.
Das Problem
Was typisch ist: eine Access-Anwendung aus 2009, ursprünglich für 50 Datensätze gedacht, läuft heute mit 3 Millionen Zeilen. Formulare hängen 8 Sekunden beim Öffnen, ein zentraler Report mit ZehnerJoins braucht 45 Sekunden. VBA-Code mit DoCmd.RunSQL aufgereiht ohne Transaktionen, Stille Fehler-Eskalation, kein Lock-Handling.
Bei 32→64-Bit-Migrationen brechen API-Deklarationen still (PtrSafe fehlt), DAO-Code stolpert über Long vs. LongPtr, ältere ODBC-Treiber verlieren Connection-Pooling. Eine Migration ohne Vorbereitung killt operative Prozesse für 1-2 Wochen.
Die häufigste falsche Frage in Access-Projekten ist 'Sollen wir das wegwerfen?'. Die richtige Frage ist 'Was kostet stabilisieren, was kostet ablösen, und was hängt geschäftlich daran?'.
Die Lösung
Erst Bestandsaufnahme, dann Entscheidung. Ich katalogisiere alle Formulare, Berichte, Abfragen, Module, externen Verknüpfungen (linked tables, ODBC-DSNs). Identifiziere kritische Pfade: was darf nicht ausfallen, was ist Karteileiche. Output ist ein Bericht mit Risiken (32-zu-64-Bit-Hotspots, Performance-Bottlenecks, Sicherheitsthemen) und drei realistischen Optionen: Stabilisieren (Refactor + Index-Tuning + Backend nach SQL Server), Replatform (Frontend bleibt, Backend wandert), oder geordnetes Ablösen (Migration auf eine moderne Architektur in 3-9 Monaten).
Bei Stabilisierung: VBA auf Option Explicit, PtrSafe-API-Deklarationen, Custom-Error-Klassen, Transaktionen wo Schreibvorgänge zusammenhängen, Index-Strategie auf der Backend-Datenbank, Backend-Migration von .accdb auf SQL Server oder PostgreSQL als Linked-Tables-Setup. Formulare und Berichte bleiben in Access, weil die UI-Schicht das ist, was Nutzer kennen.
Bei Ablösen: schrittweiser Übergang mit Coexistence-Phase, in der beide Welten parallel laufen, statt Big Bang. Daten-Migrations-Skripte mit Validierung, Test-Datensätze, Rollback-Pfad. Niemals ohne Plan B in Produktion.
Typische Anwendungsfälle
- Performance-Tuning operativer Access-Anwendungen (1-5 Mio Datensätze): Index-Strategie, Query-Refactor, Frontend-Backend-Split
- 32→64-Bit-Migration mit PtrSafe-Sweep, ADO-Aktualisierung, ODBC-Driver-Audit, vollständigem Smoke-Test-Plan
- Backend-Migration von .accdb/.mdb auf SQL Server oder PostgreSQL als Linked Tables, Formulare bleiben unverändert
- Übernahme verwaister Anwendungen: ein ehemaliger Entwickler hat das Haus verlassen, niemand traut sich ran. Code-Walkthrough, Doku-Aufbau, schrittweise Wartungs-Fähigkeit für Ihr Team
- Reports-Optimierung: Vorgang von 45 Sekunden auf 2-4 Sekunden durch SubReport-Refactor und korrekte Recordset-Strategien
- Geordnetes Ablösen einer Access-Anwendung mit Migration auf moderne Stack (Python/SQL, kleine Web-Anwendung), Coexistence-Phase
Konkreter Nutzen
- Stabilität: bestehende Investitionen weiterhin nutzbar, ohne dass die Anwendung beim nächsten Update zerbricht
- Performance: Reports und Formulare oft Faktor 5-20 schneller nach Index-Tuning und Query-Refactor
- Migrationsfähigkeit: wenn Sie später wirklich ablösen wollen, ist die Codebasis dokumentiert und der Datenfluss bekannt
- Übergabbarkeit: ein zweiter Entwickler kann das Access-System nach Übergabe übernehmen, statt es als Black Box zu meiden
- Realismus: bei Empfehlung 'wegwerfen' sage ich das offen, mit Begründung. Bei Empfehlung 'behalten' ebenso.
So läuft die Zusammenarbeit
Bestandsaufnahme (1-2 Tage)
Vollständiger Katalog: Formulare, Berichte, Abfragen, Module, externe Verknüpfungen, Benutzer-Workflows. Identifizieren kritische Pfade und Karteileichen.
Empfehlung mit drei Optionen
Stabilisieren, Replatform oder Ablösen. Jede Option mit realistischem Aufwand, Risiken, Coexistence-Strategie. Sie entscheiden auf Basis von Fakten.
Umsetzung in kontrollierten Releases
Niemals Big Bang. Jeder Release ist klein, testbar, hat einen Rollback-Pfad. Backup-Strategie vorab geklärt.
Übergabe oder Retainer
Dokumentation der Codebasis, Walkthrough mit Aufzeichnung, optional Retainer für Wartung und 32→64-Bit-Reviews bei Office-Updates.
Häufige Fragen
Sollen wir von Access weg?
Nicht pauschal. Wenn die Anwendung läuft, von 5-15 Nutzern verwendet wird, der Datenbestand unter 5-10 Millionen Zeilen bleibt und niemand mobil darauf zugreifen muss, ist Access oft die wirtschaftlichste Antwort. Wegmigriert wird, wenn Multi-User-Konflikte spürbar werden, mobiler Zugriff nötig ist, oder die Geschäftslogik so groß wird, dass sie sich nicht mehr in Formulare und Berichte zwängen lässt.
Wir müssen auf 64-Bit-Office umstellen. Wie aufwändig ist die Migration?
Hängt vom Code ab. Bei kleinen Anwendungen ohne externe DLL-Aufrufe oft 1-3 Tage. Bei Anwendungen mit ADO, Win32-API-Deklarationen, Drittanbieter-Controls 5-15 Tage. Den genauen Aufwand sehe ich nach einem Code-Scan in 4-6 Stunden.
Können wir das Backend auf SQL Server migrieren, ohne dass Nutzer etwas merken?
Ja, mit Linked Tables. Frontend bleibt unverändert, Tabellen werden auf SQL Server gespiegelt, ODBC-Verknüpfung in Access ersetzt die lokalen Tabellen. Nutzer öffnen dieselbe accde-Datei wie vorher. Vorteile: bessere Performance bei großen Datenmengen, echte Multi-User-Sperren, regelmäßige Backups, ggf. Power BI direkt auf die Datenbank.
Was machen Sie mit Access-Anwendungen, die niemand mehr versteht?
Reverse Engineering: Module für Module, Formular für Formular. Erste Phase ist nur Lesen, Verstehen, Dokumentieren. Zweite Phase erst gezielt anfassen. Niemals blind Code ändern. Wenn der Original-Entwickler weg ist, dauert das initiale Verstehen 3-6 Tage je nach Größe.
Wie hoch ist das Datenverlust-Risiko bei einer Backend-Migration?
Bei sauberer Vorgehensweise nahe null. Vorab Backup, Migrations-Skript mit Validierung (Zeilenanzahl, Aggregate, Stichprobenvergleich), Parallelbetrieb für 2-4 Wochen mit täglicher Differenzprüfung. Wenn die Differenz drei Wochen konstant null ist, wird abgeschaltet.
Passende weitere Leistungen
Access-Bestand auditieren lassen?
Beschreiben Sie die Anwendung (Größe, Nutzerzahl, Datenmenge, kritische Pain Points) oder schicken Sie eine anonymisierte Version. Sie bekommen innerhalb von zwei Werktagen eine ehrliche Einschätzung: stabilisieren, replatformen oder ablösen.