Migration wird in Wikipedia als “Umstellung auf neue Technologie, Wandlung von Daten-Formaten, Wechsel grundlegender Software” beschrieben – sofern man den Begriff Migration in der Informationstechnologie verwendet. Die soziologische Bedeutung trifft den Punkt besser: Die Daten ziehen um! Im konkreten Fall findet der Umzug von Access nach SQL Server statt. Und wie auch bei einem realen Wohnsitzwechsel kann der Datenumzug ohne Vorbereitung eine chaotische Angelegenheit werden. Daher unterstützen wir Sie: Auf den nächsten Seiten finden Sie praktische Umzug-Tipps.
Bei jeder Migration kommt immer wieder die Frage auf “Warum machen wir das nicht einfach neu”. Diese Frage ist auch durchaus berechtigt. Wenn schon eine neue Datenbasis, warum nicht auch gleich eine neue Technik einsetzen Weg von den Altlasten und alten Fehlern, die schon jahrelang in der Applikation mitgeschleppt werden, hin zu einer neuen besseren Applikation. Das würde sich ja anbieten, jetzt, da die Datenbasis auf eine neue Plattform migriert werden soll.
Natürlich ist eine Neuentwicklung der Applikation – am besten mit einer neuen Entwicklungsumgebung wie .NET – eine gute Investition für die Zukunft. Aber möchte man diese Investition überhaupt Wie hoch wäre die Investition Und Hand aufs Herz: Eine Neuentwicklung garantiert nicht unbedingt eine fehlerfreie neue Applikation. Erst recht nicht, wenn auch noch eine neue Entwicklungsumgebung genutzt wird.
Primär wären die Kosten zu prüfen. Eine Neuentwicklung kostet nicht nur Entwicklungszeit, sondern es muss auch Zeit und Geld für Schulungen investiert werden. Die Entwickler müssen in die neue Entwicklungsumgebung eingearbeitet werden, die Anwender in die neue Applikation. Denn in den seltensten Fällen sieht die Neuentwicklung später so aus wie die bestehende Applikation. Nicht nur die Optik wird dabei modernisiert, sondern meist auch der Workflow. Auch die Datenbank wird sich ändern, was den Aufwand bei der Datenübernahme erhöht.
Ein weiterer entscheidender Punkt ist die Dauer der Neuentwicklung. Die neue Applikation kann erst nach Abschluss der Entwicklung eingesetzt werden. Die vorhandenen Probleme, die Grund für die überlegung “Neuentwicklung oder Migration” sind, bleiben also bis zum Ende der Neuentwicklung bestehen, da bis zur Fertigstellung die alte Applikation weiterverwendet werden muss.
Im Gegensatz zur Neuentwicklung ist die Entwicklungszeit bei einer Migration erheblich kürzer, da hierbei nur die Access-Datenbank zu einer SQL Server-Datenbank migriert wird. Oberfläche und Programmlogik bleiben dieselbe, wodurch auch kein Schulungsaufwand entsteht. Der Erfolg einer Migration ist abhängig von dem Zustand und der Qualität der Access-Applikation. Sie sollten, bevor Sie eine Entscheidung bezüglich Migration oder Neuentwicklung treffen, zunächst testweise eine Migration durchführen.
Dieser Beitrag behandelt nur den Punkt der Migration. Denn auch ohne Thin-Clients oder Web-Applikationen mit .NET bietet allein Access schon zwei mögliche Frontends, mit denen Daten von SQL Server-Datenbanken verwaltet werden können.
Möglichkeiten
Microsoft bietet seit 2000 Access zwei verschiedene Formate an: MDB und ADP.
Während das MDB-Format als klassische Variante mit der Jet-Engine als Datenbank arbeitet, besitzt das ADP-Format (Access Database Project) keine eigene Datenbank-Engine. Das ADP-Format enthält lediglich die Formulare, Berichte, Module und Makros – sprich die Logik – der Access-Applikation und greift direkt auf den SQL Server mit seinen Tabellen, Sichten, gespeicherten Prozeduren und benutzerdefinierten Funktionen zu.
Die Daten von SQL Server-Tabellen können jedoch auch mit einer MDB verwaltet werden. Dazu werden die Tabellen über eine ODBC-Verbindung in die MDB eingebunden und dort von der Jet-Engine “adoptiert”. Jeglicher Zugriff auf die SQL Server-Tabellen wird von der Jet-Engine übernommen und gesteuert.
Microsoft propagierte für die Konstellation Access/SQL Server in den letzten Jahren die ADP.
Als Vorteil von ADP wurde der direkte Zugriff auf die SQL Server-Datenbank genannt. Es müssen keine ODBC-Verbindungen konfiguriert beziehungsweise verwaltet werden und es mischt sich keine Jet-Engine bei der Datenverwaltung ein. Auch ADO – welches als einzige Datenzugriffsbibliothek mit ADP funktioniert, denn DAO wird bei ADP nicht unterstützt – wurde stark beworben. Das ging sogar so weit, dass in den Verweisen einer neu angelegten Datenbank ADO standardmäßig aktiviert war. Wer DAO nutzen wollte, musste es manuell in Gang setzen. Es kamen sogar Gerüchte auf, dass DAO auslaufen und nicht mehr weiterentwickelt werden würde.
Neue Version, neues Glück, neue Aussagen: mit der Version Access 2007 macht Microsoft eine große Rolle rückwärts und propagiert nun MDB mit über ODBC eingebundenen Tabellen und DAO als die beste Methode, SQL Server-Datenbanken mit Access zu verwalten.
Die Aussagen, warum dies besser sei, sind jedoch etwas zweifelhaft. “Die Logik gehört in die Access-Applikation.” Stimmt auch, sofern die Datenbank nur von einer Applikation, nämlich der Access-Applikation, die die Logik beinhaltet, verwaltet wird. Werden die Daten der Datenbank aber auch von anderen Applikationen – etwa Web-Applikationen – verwaltet, ist die Logik in der Datenbank besser aufgehoben. Mal abgesehen davon, dass auch in einer ADP die Logik vorhanden ist. Viel mehr sogar: in einer ADP ist nur die Logik vorhanden.
Ein weiterer Grund soll nun das Datenhandling über die Jet-Engine sein. Gerade der direkte Zugriff ohne Umweg über die Jet-Engine wurde in den letzten Jahren als immenser Vorteil dargestellt und als Grund für den Wechsel auf ADP propagiert.
Die Möglichkeit, temporäre Daten in lokalen Tabellen einer MDB zwischenzuspeichern, wird auch als Grund genannt. Dies kann unter Umständen schon ein Vorteil sein, aber es ist durchaus auch möglich, temporäre Daten auf dem SQL Server zu speichern.
Ein weitaus wichtigerer – wenn auch eher verschwiegener – Grund gegen ADP ist die mangelnde Weiterentwicklung: Für SQL Server 2000-Datenbanken stehen in den ADP-Versionen 2000-2003 die entsprechenden Verwaltungstools zum Erstellen von Tabellen, Sichten und gespeicherten Prozeduren zur Verfügung. Die Tools sind in diesen Versionen für den SQL Server 2005 nicht mehr nutzbar. Die ADP-Versionen 2000-2003 kommen auch mit dem neuen Security-Konzept des SQL Server 2005 – speziell mit den Schemata – nicht zurecht. Erst in Access 2007 stehen die entsprechenden Tools für die neuen Features von SQL Server 2005 zur Verfügung und auch die Schemata werden erkannt. Womit der Weg für die ADP wieder frei wäre, gäbe es da nicht den Umstand, dass die Neuerungen von Access 2007 eher in die Weiterentwicklung von Jet (ACE) eingeflossen sind und die ADP mehr als stiefmütterlich behandelt wird. Diese stiefmütterliche Behandlung wird schon dadurch deutlich, dass das ADP-Format in Access 2007 erst einmal gefunden werden muss. Es ist so beiläufig integriert, dass während der Betaphase schon das Gerücht aufkam, ADP sei tot. An jedem Gerücht soll ja ein Fünkchen Wahrheit sein und man darf gespannt sein, ob und wie lange Microsoft das ADP-Format aufrechterhält.
Auf alle Fälle sollten Sie den aktuellen Status der ADP-Entwicklung in Ihre Migrationsüberlegungen mit einbeziehen.
Ob Sie nun aber ADP oder MDB bevorzugen: In beiden Fällen müssen Sie Ihre Datenbank noch prüfen und ggf. auf die Migration vorbereiten.
Vorbereitungen
Sicherung! Sie sollten – und das ist ja wohl selbstverständlich – Ihre Datenbank vor der Migration sichern. Am besten migrieren Sie erst mal nur eine Kopie Ihrer Datenbank.
Sie werden in einigen Fällen feststellen, dass an der Datenbank noch manuelle änderungen notwendig sind, damit Ihre Access-Applikation mit der migrierten Datenbank arbeiten kann. Eine dieser änderungen betrifft den Primärschlüssel. Der Primärschlüssel spielt eine entscheidende Rolle für die Migration. Daten von SQL Server-Tabellen, die keinen Primärschlüssel haben, können mit Access nicht geändert werden. Dabei ist es unwichtig, ob Sie nun eine ADP oder MDB einsetzen möchten. Jede Tabelle muss einen Primärschlüssel besitzen! Sollten Sie Tabellen ohne Primärschlüssel in Ihrer Datenbank haben, gönnen Sie diesen Tabellen nun einen Primärschlüssel; ein Autowert reicht völlig aus.
Mit dem Primärschlüssel wäre dann auch schon das größte Hindernis genannt. Für das Leben und insbesondere für die Weiterentwicklung der Access-Applikation nach der Migration sollten Sie noch wissen, dass Access und SQL Server mit unterschiedlichen Datentypen arbeiten. Erschwerend kommt dazu, dass in beiden Systemen gleiche Bezeichnungen für unterschiedliche Datentypen verwendet werden. Beispielsweise ist ein “integer” im SQL Server ein “longint” in Access oder “text” im SQL Server in Access ein “memo”. Natürlich sollten Sie auch überlegen, was alles migriert werden soll beziehungsweise muss. Für eine ADP müssen alle Tabellen und Abfragen migriert werden, da die ADP selbst weder Tabellen noch Abfragen speichern kann. Die vorhandenen Access-Abfragen werden dabei als Sichten oder gespeicherte Prozeduren exportiert.
Sofern weiterhin mit einer MDB gearbeitet wird, können nach Belieben alle oder auch nur einige Tabellen migriert und in die MDB eingebunden werden. Auch die Migration der Abfragen zu Sichten und gespeicherten Prozeduren ist möglich, wobei jedoch nur die Sichten direkt in der MDB genutzt werden können. Diese Limitation wird die Migration von einigen Abfragen verhindern. Zum Beispiel müssen Abfragen mit Parameterwerten zu gespeicherten Prozeduren konvertiert werden, da Sichten Parameter nicht unterstützen. Aber gespeicherte Prozeduren wiederum können nicht direkt wie Tabellen in der MDB verwendet, sondern nur in VBA ausgeführt werden. Die einzige Möglichkeit, SQL Server-Objekte als Objekte in einer MDB zu nutzen, besteht darin, die SQL Server-Objekte als Tabellen einzubinden. Das ist mit gespeicherten Prozeduren nicht möglich, wohl aber mit Sichten: Diese werden als Tabellen in die MDB eingebunden – wobei wieder der Primärschlüssel ins Spiel kommt. Beim Einbinden einer Sicht als Tabelle müssen Sie eine Spalte als Primärschlüssel deklarieren, sonst stehen die Daten lediglich schreibgeschützt zur Verfügung.
Sofern Sie die Abfragen mit in Ihren Migrationsplan aufnehmen, müssen Sie auch diese vorab prüfen. Abfragen mit Verweisen auf Controls wie Forms!FormName!Control oder Abfragen mit VBA-Funktionen wie Format können nicht migriert werden. Der Grund dafür ist recht einfach: der SQL Server kennt weder die Access-Controls noch die VBA-Funktionen, und was der SQL Server nicht kennt, wird auch nicht migriert.
Entweder verzichten Sie auf die Migration dieser Abfragen oder Sie programmieren diese Abfragen als Sichten beziehungsweise gespeicherte Prozeduren. Dazu sind Kenntnisse in T-SQL, der SQL-Syntax des Microsoft SQL Servers, notwendig. Auch die Möglichkeiten der Sichten und gespeicherten Prozeduren sollten Ihnen bekannt sein, um abschätzen zu können, wann eine Abfrage durch eine Sicht oder eine gespeicherte Prozedur ersetzt werden kann oder muss.
Eine andere Variante wäre, die Notwendigkeit der Abfragen beziehungsweise deren Syntax zu überdenken. Bei Abfragen mit VBA-Funktionen etwa sollten Sie prüfen, ob diese VBA-Funktionen in der Abfrage zwingend erforderlich sind. Beispielsweise könnte eine Format-Funktion auch erst bei der Anzeige beziehungsweise Weiterverarbeitung eingesetzt werden und nicht unbedingt in der Abfrage selbst. Solch “bereinigte” Abfragen werden anstandslos migriert.
Eine gut vorbereitete Access-Datenbank wird bei der Migration keine großen Probleme verursachen. Aber wie funktioniert nun eine solche Migration Dafür gibt es entsprechende Tools.
|
Migration ohne Tools |
|
Sofern Sie nur die Tabellen einer Access-Datenbank migrieren wollen und die Anzahl dieser Tabellen überschaubar ist, ist eine manuelle Migration durchaus eine Alternative. Dabei lernen Sie nicht nur das SQL Server Management Studio, sondern auch einige Feinheiten bei der Erstellung von SQL Server-Datenbanken, Tabellen und Indizes kennen. Bei der manuellen Migration legen Sie die Datenbank auf dem SQL Server an sowie anschließend jede einzelne Tabelle mitsamt den Spalten und den entsprechenden Datentypen, so wie sie auch in Ihrer Quelldatenbank vorhanden sind. Ergänzend können Sie dazu noch die Gültigkeitsregeln als Check Constraints, die Standardwerte als Default, sowie die jeweiligen Indizes und Fremdschlüssel der Tabellen mitsamt den Lösch- und Aktualisierungsweitergaben festlegen. Nachdem alle Tabellen vollständig auf dem SQL Server erstellt sind, wechseln Sie zur MDB und binden die SQL Server-Tabellen dort über ODBC ein. Anschließend kopieren Sie die Daten jeweils von der lokalen zur eingebundenen Tabelle. Dabei müssen Sie die Beziehungen der Tabellen und die damit verbundene Abhängigkeit und Reihenfolge berücksichtigen. Das Ermitteln dieser Reihenfolge kann sich bei Access-Datenbanken mit vielen Beziehungen zu einer ausgeprägten Geduldsprobe entwickeln. Um sich die Arbeit etwas zu erleichtern, nutzen Sie den Datenbank-Dokumentator von Access, den Sie unter Datenbank/Dienstprogramme finden. Dieser liefert eine ausführliche übersicht der Tabellen und ihrer Abhängigkeiten. |
Migration mit dem Upsizing-Assistenten
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
