Migration von Microsoft-Access nach .NET

Beweggründe

MS-Access ist Microsofts Antwort auf die täglich anfallenden Aufgaben des Geschäftslebens wie Berichte, Auswertungen und Datenerfassung. Es ist leicht zu erlernen, schnell zu erweitern und führt auf direktem Weg zu den gewünschten Ergebnissen.

Diese Fähigkeiten werden Ms-Access durch die enge und intuitive Integration von Datenbank, Berichtsgenerator und Dialog-Designer verliehen. Dieser monolithische Aufbau ist ebenfalls der Grund, der eine Lösung in Access am Wachsen hindert. Für die folgenden Fälle gibt es innerhalb der Ms-Access-Welt keine praktikablen Lösungen:

• Mehrplatzfähigkeit
• Datengrößen über 500 Megabyte
• Einbindung in Webseiten
• Mehr als ein Entwickler

Wenn Ihre Anwendung mit ihrem Unternehmen mitwächst, werden zumeist mehrere dieser Probleme gleichzeitig auf Sie zukommen. Innerhalb der bekannten Technologie sind diese Anforderungen nur mit extremen Mehraufwand und unsauberen Tricks zu erreichen.

Wege aus der Krise

An dieser Stelle werden dann Überlegungen laut die Anwendung mit einer neuen Plattform neu zu schreiben, was in der Regel aber als undurchführbar oder zu teuer erachtet wird. Damit beginnt das "Basteln" und der schleichende Verlust der Software-Qualität und der Nutzerzufriedenheit. Oft ist der Kollaps der Software oder ein enormer finanzieller Aufwand die Folge.

An dieser Stelle bieten wir Ihnen eine dritte Alternative, die Schritt für Schritt aus der Krise führt und Ihre Anwendung zu jedem Zeitpunkt einsatzbereit und erweiterbar erhält:

Die schrittweise Migration auf Microsofts .NET-Plattform

Die technischen Hilfsmittel stammen alle aus dem Hause Microsoft und sind in kostenlosen Versionen verfügbar:

• .NET-Framework
• MS SQL Server 2008 Express
• MS Visual C#/VB.NET Express
• MS SQL-Native ODBC-Driver

Wie man diese Werkzeuge einsetzt und miteinander kombiniert haben wie in zahlreichen Projekten erprobt und können nun eine wirksame Vorgehensweise vermitteln, die Ihnen böse Überraschungen und damit Kosten erspart.

Die Reise beginnt

Schritt1: Migration der Daten in den SQL Server
Zunächst werden die bestehenden Daten und Tabellenstrukturen der Ms-Access Datei in eine SQL-Server-Instanz verschoben und ODBC-Verknüpfungen der neuen Datenbank in Ms-Access angelegt.

Schritt 2: Einführung einer COM-Bridge
Ms-Access und .NET basieren auf grundlegend verschiedenen Grundlagen und können nicht direkt miteinander interagieren. Als Schnittstellen-Technologie die von Beiden verstanden wird setzen wir das Component Object Model (COM) ein, mit dessen Hilfe eine direkte Verbindung zwischen Ms-Access und Ihren neuen .NET-Komponenten hergestellt wird.

Schritt 3: IoC-Container & DI
Mithilfe eines selbsterstellen Microkernels der auf dem Inversion of Control-Pattern (IoC) und dem Dependency Injection-Pattern (DI) basiert schaffen wir eine strikte vertragsbasierte Trennung zwischen allen neu erstellten Funktionen Ihrer Anwendung, so dass verschiedene Entwickler gleichzeitig arbeiten können und die Einzelteile automatisiert getestet werden können.

Schritt 4: Migration
Einzelne, möglichst unkritische Programmteile ihrer Ms-Access-Lösung werden in .NET neu erstellt und parallel zu der alten Version in die Anwendung eingeflochten. So kann im Fehlerfall auf die alte funktionierende Version umgeschaltet werden und die Software bleibt permanent einsatzbereit.

Schritt 5: Erstellen eines Start -Containers
Ihre Anwendung startet immer noch auf Basis von Ms-Access und blendet die neuen Programmteile lediglich in das alte Programm ein. Ziel ist es, die neuen Programmteile direkt zu starten und die alten Teile einzublenden. Dazu wird ein Start-Container erstellt, in dem alle neuen Programmteile experimentell gestartet werden können. Aus diesem Experimentierkasten erwächst langsam der neue Programmrahmen.

Schritt 6: Umkehr
Ab einer kritischen Masse von migrierten Funktionen und Programmteilen wird das Startprinzip umgekehrt und die verbleibenden Ms-Access –Module über Startparameter aus der neu erwachsenen Applikation gestartet.

Schritt 7: Aufräumen
Während der Migration müssen häufig Kompromisse gemacht werden und wegen der teilweisen Parallelität von alter und neuer Programmwelt Aufräumarbeiten an den Schluss der der Umstellung verschoben werden. Das Bereinigen der Datenbank und Entfernen der kompatibilitätsgeschuldeten Strukturen (wie der COM-Bridge) gilt nun die Aufmerksamkeit

Wichtige Grundsätze

• Migrierte Funktionen sollten immer parallel zu den Alten zur Verfügung gestellt werden, so dass im Fehlerfall auf die alten Programmteile zurückgegriffen werden kann und Ihre Software immer einsetzbar bleibt
• Auf gar keinen Fall sollten alte Programmteile gelöscht werden, da häufig unvorhergesehene Programmteile auf gelöschte Programmteile zugreifen, was zu unnötigen Komplikationen führt.
• Die Struktur der Daten soll nur leicht verändert werden und besser durch einen so genannten O/R-Mapper für die neuen Programmteile verpackt werden, so dass die Programmteile auf eine korrekte Datenstruktur zugreifen können und der O/R-Mapper auf die originale Struktur übersetzt.
• Während der Migrationsphase sollten keine grundlegenden Erweiterungen und Wünsche umgesetzt werden, da diese in der Regel in der alten und neuen Programmwelt durchgeführt werden müssen und so zu Inkonsistenzen und doppeltem Aufwand führen
• Die vorgenommen Änderungen sollten möglichst klein sein und so häufig wie möglich ausgeliefert werden. So bleiben die Änderungen für den Benutzer minimal und die immer wieder anfallende Einarbeitung in neue Programmteile überschaubar.

Fallstudie

In den vergangenen 4 Jahren haben wir mehr als 15 Projektumstellungen von Ms-Access auf die .NET-Plattform durchgeführt. Darunter waren namhafte Kunden wir Thyssen Krupp und die Deutsche Post. Ein seit 2 Jahren begleitetes Projekt ist die Umstellung der Software Senocare, zur Verwaltung von Altenheimen, für die Firma ac-data GmbH. Dazu ein paar Zahlen.

• 85 Datenbanktabellen
• 40 Datenbankviews
• 112 Dialoge
• Abhängigkeit zu 8 externen Bibliotheken
• Über 100 gleichzeitige Anwender
• Über 9 GB Daten in einer Datenbank
• 350.000 Codezeilen
• 178 Einzeprojekte
• Mehr als 1000 automatisierte Tests
• Übersetzungszeit 3 Mannjahre

Das beweist: Unmöglich gibt es nicht!