Migration von Access zum SQL Server 2005

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 mit dem Upsizing-Assistenten

Seit Access 2000 scheint Microsoft bei jeder Access-Version damit zu rechnen beziehungsweise zu hoffen, dass die damit erstellten Datenbanken irgendwann einmal zu SQL Server-Datenbanken migriert werden. Denn seit Access 2000 ist immer ein Upsizing-Assistent dabei; für Access 97 wurde er noch schnell als Download nachgereicht.

Auch in der neuesten Version – in Access 2007 – ist der Upsizing-Assistent enthalten. Wie in den vorherigen Versionen auch kann mit dem Assistenten eine ADP erstellt oder eine bestehende MDB verändert werden. Im Assistenten wird definiert, auf welchen SQL Server mit welcher Anmeldung die Tabellen mit Indizes, Beziehungen und Daten migriert werden. Doch der Reihe nach – und zwar Schritt für Schritt – und das mit der Nordwind-Datenbank.

Im folgenden Beispiel wird beschrieben, wie die Nordwind-Datenbank aus Access 2007 mit dem Upsizing-Assistenten migriert wird. Sie können auch Access 2003 dafür verwenden. Der Upsizing-Assistent hat sich nicht verändert.

öffnen Sie die Nordwind-Datenbank und starten Sie den Upsizing-Assistenten. Sie finden ihn in Access 2007 in der Multifunktionsleiste unter Datenbanktools/Daten verschieben/SQL Server; in Access 2003 findet er sich im Menü Extras/Datenbank-Dienstprogramme/Upsizing-Assistent.

Der erste Dialog des Upsizing-Assistenten verlangt von Ihnen die Entscheidung, ob die Tabellen der geöffneten Datenbank in eine neue oder in eine bestehende SQL Server-Datenbank migriert werden sollen.

Die Migration der Tabellen in eine bestehende SQL Server-Datenbank ist nützlich, wenn Sie umfangreiche Access-Applikationen migrieren und dabei den Migrationsprozess in mehrere Schritte aufteilen möchten. Im ersten Schritt erstellen Sie eine neue Datenbank und in den darauf folgenden Schritten verbinden Sie sich mit dieser. Für diese Verbindung wird eine entsprechende ODBC-Verbindung benötigt.

In diesem Beispiel soll eine neue Datenbank erstellt werden. Insofern können Sie die Vorauswahl beibehalten und auf Weiter klicken.

Die Auswahl des SQL Servers, auf dem die Datenbank erstellt werden soll, sowie die dazu notwendige Anmeldung und der Name der neuen Datenbank sind Inhalt des nächsten Dialogs (siehe Bild 1).

Als Anmeldemöglichkeiten stehen die bekannte „vertrauenswürdige Verbindung“ – also die Windows-Authentifizierung – und eine Anmeldung mit Benutzername und Kennwort – die SQL Server-Authentifizierung – zur Verfügung. Wenn Sie die SQL Server-Authentifizierung nutzen, sollten Sie bedenken, dass der eingegebene Benutzername auf dem SQL Server existieren und dort auch über die entsprechenden Rechte zur Anlage einer Datenbank verfügen muss. Natürlich muss auch das Kennwort dort mit dem hier eingegebenen Kennwort übereinstimmen.

Den bereits vorgegebenen Datenbanknamen können Sie nach Belieben ändern. Mit einem Klick auf Weiter wird die Datenbank angelegt und der nächste Dialog (siehe Bild 2) geöffnet. Hier wählen Sie die Tabellen aus, die migriert werden sollen. Eine Auswahl der Abfragen gibt es nicht. Sofern Sie eine ADP durch den Assistenten erstellen lassen, werden die Abfragen automatisch migriert.

Für die Migration der Nordwind-Datenbank wählen Sie alle Tabellen aus. Anschließend öffnen Sie den nächsten Dialog mit einem Klick auf Weiter.

Der vierte Dialog (siehe Bild 3) des Upsizing-Assistenten ermöglicht die Konfiguration der Tabellenattribute und der übernahme der Daten. Als konfigurierbare Tabellenattribute stehen Indizes, Standardwerte und Gültigkeitsregeln zur Verfügung. Durch Aktivierung der einzelnen Optionen werden die Access-Indizes als SQL Server-Indizes, die Standardwerte als Defaults und die Gültigkeitsregeln als Check-Contraints konvertiert – sofern die in Access verwendete Syntax vom SQL Server verstanden wird.

Die Tabellenbeziehungen mitsamt den Aktualisierungs- und Löschweitergaben werden durch die gleichnamige Option aktiviert. Sie müssen sich jedoch entscheiden, ob die Beziehungen im SQL Server über DRI oder über Trigger dargestellt werden sollen. In beiden Fällen werden die Tabellenbeziehungen über Foreign Keys abgebildet. Für die Aktualisierungs- und Löschweitergaben gibt es jedoch zwei Möglichkeiten: Mit DRI wird die Aktualisierungs- und Löschweitergabe in den Foreign Keys selbst aktiviert, während bei der Option Mit Trigger für Aktualisierungs- und Löschweitergaben neue Trigger auf dem Server erstellt werden.

DRI ist für die einfache Abbildung der Aktualisierungs- und Löschweitergabe absolut ausreichend und auch der aus Access bekannten am nächsten. Die Variante der Trigger bietet den Vorteil, dass der Code der jeweiligen Aktualisierungs- und Löschweitergaben jederzeit erweitert werden kann.

Im Bereich Datenoptionen steht noch ein für die Migration entscheidendes Kriterium zur Auswahl: Die Erweiterung der Tabellen durch ein Timestamp-Feld. Dies ist nicht unbedeutend, da eine Timestamp-Spalte in manchen Tabellen für ein schnelleres Update der Datensätze sorgt.

Denn bei einem Update eines Datensatzes ohne Timestamp-Spalte werden der Primärschlüssel und die Daten jeder Spalte des angezeigten Datensatzes mit dem Primärschlüssel und den Daten jeder Spalte des gespeicherten Datensatzes verglichen. Bei unterschiedlichen Daten sieht der SQL Server das Kriterium als erfüllt an, geht also von einer Datenänderung aus, und führt das Update durch.

Access arbeitet mit anderen Datentypen beziehungsweise mit anderen Genauigkeiten, wodurch die angezeigten Werte sich bei einigen Datentypen immer von den gespeicherten Werten unterscheiden. Dadurch kommt es häufig zu Updates, obwohl eigentlich keine wirkliche Datenänderung stattgefunden hat.

Um dies zu vermeiden, sollte eine Spalte vom Typ Timestamp in den Datensatz aufgenommen werden. Hier wird nicht – wie der Name vielleicht suggeriert – ein Zeitpunkt festgehalten, sondern ein binärer Wert, der den Zustand des Datensatzes beschreibt. Beim Update werden jetzt nur noch der Primärschlüssel und der Wert der Timestamp-Spalte verglichen. Nur wenn sich der Wert der Timestamp-Spalte verändert hat, wird das Update ausgeführt.

Die Option bietet drei Möglichkeiten, von denen standardmäßig Ja – der Assistent soll entscheiden markiert ist. Diese Option ist auch sinnvoll, da der Assistent nun prüft, ob für die jeweilige Tabelle eine Timestamp-Spalte notwendig ist. In der Regel sind dies Tabellen, die Spalten vom Datentyp Single, Double, Memo oder OLE-Objekt enthalten.

Sofern Sie nur die Struktur der Tabellen, aber keine Daten migrieren möchten, müssen Sie lediglich die Option Nur Tabellenstruktur erstellen, keine Daten aktivieren. Nachdem Sie die Tabellenattribute und Datenübernahme konfiguriert haben, können Sie mit Weiter zum nächsten Dialog (siehe Bild 4) wechseln.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo