<\/p>\n
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.<\/b><\/p>\n<\/div>\n 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.<\/p>\n 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.<\/p>\n 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. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n Microsoft bietet seit 2000 Access zwei verschiedene Formate an: MDB und ADP. <\/p>\n 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. <\/p>\n 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. <\/p>\n Microsoft propagierte für die Konstellation Access\/SQL Server in den letzten Jahren die ADP. <\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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. <\/p>\n Auf alle Fälle sollten Sie den aktuellen Status der ADP-Entwicklung in Ihre Migrationsüberlegungen mit einbeziehen.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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<\/b> oder Abfragen mit VBA-Funktionen wie Format<\/b> 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.<\/p>\n 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. <\/p>\n 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<\/b>-Funktion auch erst bei der Anzeige beziehungsweise Weiterverarbeitung eingesetzt werden und nicht unbedingt in der Abfrage selbst. Solch „bereinigte“ Abfragen werden anstandslos migriert.<\/p>\n 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.<\/p>\n Migration ohne Tools<\/p>\n<\/td>\n<\/tr>\n 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 <\/b>finden. Dieser liefert eine ausführliche übersicht der Tabellen und ihrer Abhängigkeiten. <\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n <\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n ö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<\/b>; in Access 2003 findet er sich im Menü Extras\/Datenbank-Dienstprogramme\/Upsizing-Assistent<\/b>.<\/p>\n 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. <\/p>\n 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.<\/p>\n In diesem Beispiel soll eine neue Datenbank erstellt werden. Insofern können Sie die Vorauswahl beibehalten und auf Weiter <\/b>klicken.<\/p>\n 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).<\/p>\n Bild 1: Die neue Adresse der Datenbank<\/span><\/b><\/p>\n<\/p><\/div>\n 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.<\/p>\n Den bereits vorgegebenen Datenbanknamen können Sie nach Belieben ändern. Mit einem Klick auf Weiter <\/b>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.<\/p>\n Bild 2: Auswahl der Tabellen<\/span><\/b><\/p>\n<\/p><\/div>\n 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<\/b>.<\/p>\n 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.<\/p>\n Bild 3: Tabellenattribute und Datenoptionen<\/span><\/b><\/p>\n<\/p><\/div>\n 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<\/b> wird die Aktualisierungs- und Löschweitergabe in den Foreign Keys selbst aktiviert, während bei der Option Mit Trigger<\/b> für Aktualisierungs- und Löschweitergaben neue Trigger auf dem Server erstellt werden. <\/p>\n DRI <\/b>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.<\/p>\n Im Bereich Datenoptionen <\/b>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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Um dies zu vermeiden, sollte eine Spalte vom Typ Timestamp <\/b>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<\/b>-Spalte verglichen. Nur wenn sich der Wert der Timestamp<\/b>-Spalte verändert hat, wird das Update ausgeführt.<\/p>\n Die Option bietet drei Möglichkeiten, von denen standardmäßig Ja – der Assistent soll entscheiden <\/b>markiert ist. Diese Option ist auch sinnvoll, da der Assistent nun prüft, ob für die jeweilige Tabelle eine Timestamp<\/b>-Spalte notwendig ist. In der Regel sind dies Tabellen, die Spalten vom Datentyp Single<\/b>, Double<\/b>, Memo<\/b> oder OLE-Objekt<\/b> enthalten.<\/p>\n Sofern Sie nur die Struktur der Tabellen, aber keine Daten migrieren möchten, müssen Sie lediglich die Option Nur Tabellenstruktur erstellen, keine Daten <\/b>aktivieren. Nachdem Sie die Tabellenattribute und Datenübernahme konfiguriert haben, können Sie mit Weiter <\/b>zum nächsten Dialog (siehe Bild 4) wechseln.<\/p>\n Bild 4: Auswahl ADP oder MDB<\/span><\/b><\/p>\n<\/p><\/div>\n Hier haben Sie die Möglichkeit zu entscheiden, ob aus der Access-Applikation eine ADP erstellt wird oder ob die neuen SQL Server-Tabellen in die bestehende MDB eingebunden werden sollen. Es ist auch möglich, nur die Migration der Tabellen auszuführen und die geöffnete Access-Applikation nicht zu verändern. Die Auswahl ist entscheidend für den Umfang der Migration. Nur bei der Migration zu einer ADP werden auch die Abfragen zu Sichten beziehungsweise gespeicherten Prozeduren migriert. Die zweite und dritte Option migriert nur die ausgewählten Tabellen. Wählen Sie für dieses Beispiel die erste Option, um auch die Abfragen testweise zu migrieren.<\/p>\n Durch Aktivieren der Option Kennwort und Benutzer-ID speichern <\/b>wird die Anmeldung an der SQL Server-Datenbank in Zukunft automatisiert. Das Kennwort wird bei einer MDB in den Access-Systemtabellen gespeichert, während die ADP – aus Mangel an eigenen Tabellen – die Anmeldung lesbar in einer Datei speichert. Sie haben richtig gelesen: Die angegebene Benutzeranmeldung wird im Klartext hinterlegt!<\/p>\n Um dies zu vermeiden, bleibt Ihnen nur die Vertraute Verbindung<\/b>. Oder Sie verzichten auf die automatische Anmeldung und muten dem Anwender zu, dass er sich bei jedem Start der Applikation an der SQL Server-Datenbank anmelden muss. <\/p>\n Mit einem Klick auf Weiter <\/b>gelangen Sie zum letzten Dialog des Assistenten. Hier bestimmen Sie, ob die neu erstellte ADP nach der Migration geöffnet werden soll oder ob Sie mit der geöffneten Access-Datenbank weiterarbeiten möchten. Sofern Sie keine ADP erstellen wollen, sehen Sie einen leeren Dialog, der nur die Schaltfläche Fertig stellen <\/b>zum Starten der Migration bietet. <\/p>\n Während des Migrationsprozesses werden Sie informiert, welche Tabelle gerade migriert wird. Am Ende der Migration erhalten Sie einen Migrationsbericht, den Sie unbedingt speichern sollten. Dort sind alle migrierten und nicht migrierten Tabellen und Abfragen mit den entsprechenden Warnungen und Fehlern protokolliert. Anhand dieses Berichts können Sie beurteilen, ob Ihre Migration ein Erfolg war beziehungsweise die Gründe für aufgetretene Fehler einsehen.<\/p>\n Wie bereits kurz angesprochen, werden die Abfragen nur bei der Erstellung einer ADP migriert. Mit einem kleinen Trick können Sie auch die Abfragen migrieren lassen, ohne später mit einer ADP arbeiten zu müssen:<\/p>\n Nachdem der Upsizing-Assistent die Migration beendet und die Tabellen in die MDB eingebunden hat, starten Sie die Migration mit denselben Einstellungen nochmals. Sie müssen sich nun nur mit der bereits bestehenden Datenbank verbinden und im vorletzten Dialog des Assistenten die Option Eine neue Access-Client\/Server-Anwendung erstellen <\/b>aktivieren.<\/p>\n Nun werden lediglich die Objekte migriert, die noch nicht in der SQL Server-Datenbank vorhanden sind. Das bedeutet: die ausgewählten Tabellen werden nicht migriert, dafür aber die Abfragen. Der Migrationsbericht zeigt Ihnen anschließend detailliert, welche Abfragen migriert werden konnten und welche aus angegebenen Gründen nicht.<\/p>\n Der Clou: Die bei diesem Vorgang erstellte ADP kann nach dem Migrationsprozess wieder gelöscht werden. <\/p>\n Es gibt noch eine weitere, elegantere Alternative, um die Abfragen – und natürlich auch die Tabellen – zu migrieren: den SQL Server Migrations-Assistenten für Access.<\/p>\n Unabhängig von den Upsizing-Assistenten bietet Microsoft seit dem SQL Server 2005 nun auch den SQL Server Migrations-Assistenten – kurz SSMA – für Access als allein stehende Anwendung an. Der SSMA kann unter http:\/\/www.microsoft Der SSMA macht im Grunde genommen nichts anderes, als die in Access verfügbaren Upsizing-Assistenten. Nur wird dabei ein anderer Ansatz verfolgt: Während der Upsizing-Assistent die Tabellen einer Access-Applikation komplett in einem Rutsch migriert, kann beim SSMA jeder Schritt einer Migration einzeln durchgeführt und dokumentiert werden.<\/p>\n Dieser Ansatz ist bedingt durch den eigentlichen Ursprung des SSMA, denn es gibt den SSMA für Oracle, den SSMA für Sybase und halt auch den SSMA für Access. Für die Migration großer Datenbankserver wie Oracle und Sybase ist die Möglichkeit einer sukzessiven Migration sehr sinnvoll.<\/p>\n Der Fokus der Migration liegt beim SSMA auf den Tabellen, Abfragen und Daten. Im Gegensatz zum Upsizing-Assistenten wird dabei die Applikation – also Formulare, Berichte, Code – nicht berücksichtigt, d. h. die automatische Erzeugung einer ADP ist nicht möglich. Dafür werden die Abfragen im SSMA nicht stiefmütterlich behandelt, sondern können wie die Tabellen für die Migration einzeln ausgewählt werden. <\/p>\n Doch jetzt zur Migration im Einzelnen. Wieder soll die Nordwind-Datenbank migriert werden und dazu starten Sie den SSMA.<\/p>\n Als Erstes sehen Sie den Migration-Wizard mit einer übersicht, welche Aktionen nun durchgeführt werden. Der Wizard ist für einfache und schnelle Migrationen ausreichend, aber er versteckt einige interessante Optionen. Um diese Optionen kennen zu lernen, zeigt dieses Beispiel die Migration der Nordwind-Datenbank ohne Wizard. Dazu müssen Sie erst den Wizard schließen. <\/p>\n So ganz ohne Unterstützung legen Sie nun also zunächst über File\/New Project <\/b>ein neues Projekt an. Mit diesem Projekt sind Sie in der Lage, den jeweiligen Migrationsstand zu speichern und jederzeit wieder fortzusetzen. <\/p>\n Im Dialog New Project <\/b>(siehe Bild 5) bestimmen Sie Speicherort und Name für dieses Migrationsprojekt.<\/p>\n Bild 5: Ein neues Migrationsprojekt<\/span><\/b><\/p>\n<\/p><\/div>\n Als Nächstes müssen Sie die zu migrierende Access-Datenbank in das Projekt laden. Mit dem Menübefehl Find Databases <\/b>können Sie mehrere Datenbanken suchen lassen und in das Projekt aufnehmen. Es ist möglich, mehrere Datenbanken in einem Projekt zu migrieren. <\/p>\n Für dieses Beispiel reicht die Nordwind-Datenbank, die Sie direkt mit dem Menübefehl Add Databases <\/b>in das Projekt laden können. Anschließend werden die Metadaten, also das Schema, der Datenbank ausgelesen und in einer Baumansicht dargestellt.<\/p>\n Auf Ebene des Knoten Tabellen <\/b>sehen Sie auf der rechten Hälfte des SSMA eine Mapping-Tabelle (siehe Bild 6), die die Konvertierung der Datentypen aus Access nach SQL Server darstellt.<\/p>\n Bild 6: Mapping-Tabelle<\/span><\/b><\/p>\n<\/p><\/div>\n Sie können eine Tabelle mit eigenen Konvertierungen erweitern oder bestehende Konvertierungen ändern. <\/p>\n Die Mapping-Tabelle kann auch in den Projekt-Optionen über Tools\/Projekt Settings <\/b>konfiguriert werden. Dort stehen auch viele weitere nützliche Optionen, wie die Ergänzung von Timestamp<\/b>-Feldern, die automatische Ergänzung von Primärschlüsseln bei Tabellen ohne Primärschlüssel sowie die Einstufung bestimmter Ereignisse als Fehler oder Warnungen zur Verfügung.<\/p>\n Auch die Datenmigration bietet verschiedene Optionen. Sie können etwa angeben, ob und wie fehlerhafte Datumsangaben korrigiert werden oder ob die Daten ohne Check-Constraints und Trigger auf Seiten der Zieltabellen migriert werden sollen.<\/p>\n Zur Fortsetzung der Migration benötigen Sie eine Verbindung zum SQL Server, die Sie über den Menübefehl Connect to SQL Server <\/b>konfigurieren. <\/p>\n Sofern eine neue Datenbank erstellt werden soll, müssen Sie lediglich den neuen Namen der Datenbank in das Feld Database <\/b>eintragen. Dies hat eine Abfrage zur Folge, mit der Sie die Anlage der neuen Datenbank bestätigen. <\/p>\n Nun sind die Grundsteine gelegt: Die Quelle und das Ziel sind bekannt (siehe Bild 7).<\/p>\n Bild 7: Quelle und Ziel der Migration<\/span><\/b><\/p>\n<\/p><\/div>\n Bevor Sie jetzt mit der eigentlichen Migration beginnen, gibt es die Möglichkeit, die Migration zu simulieren. Die Ergebnisse der Simulation werden in einem interaktiven Bericht zusammengefasst. Dadurch haben Sie Gelegenheit, die Access-Datenbank für die Migration anzupassen, bevor auch nur ein Objekt tatsächlich auf den SQL Server migriert wurde. <\/p>\n Markieren Sie die Nordwind-Datenbank im Baum Access-Metadata <\/b>und klicken Sie auf den Menübefehl Create Report<\/b>. Sie erhalten einen ausführlichen interaktiven Bericht (siehe Bild 8), der umfassende Beschreibungen der Fehler und Warnungen, sowie der migrierbaren Objekte enthält.<\/p>\n Bild 8: Für die wirkliche Migration müssen Sie zunächst ein Schema anhand der Access-Objekte erstellen lassen, dieses auf den SQL Server übertragen und anschließend die Daten migrieren. <\/p>\n Dazu starten Sie die einzelnen Schritte mit den Befehlen Convert Schema<\/b>, Load to Database <\/b>und Migrate Data <\/b>aus der Menüleiste.<\/p>\n Convert Schema <\/b>konvertiert das Schema der Access-Datenbank in ein Schema für die SQL Server-Datenbank. Im Ausgabefenster sehen Sie die entsprechenden Ergebnisse, Fehler und Warnungen.<\/p>\n Die konvertierten Objekte werden aber noch nicht auf dem SQL Server angelegt. Dazu müssen Sie zunächst das Schema des SQL Servers markieren und im Menü Load to Database <\/b>anklicken. Erst jetzt wird das erstellte Schema auf die SQL Server-Datenbank angewendet und die Tabellen und Abfragen werden erstellt. <\/p>\n Der letzte Schritt ist die Migration der Daten, die Sie per Migrate Data <\/b>starten. Damit die Schaltfläche aktiv ist, müssen Sie die Datenbank Nordwind im Baum Access-Metadata <\/b>markieren.<\/p>\n Sie können diese drei Aktionen auch direkt in einem Rutsch per Convert<\/b>, Load <\/b>and Migrate <\/b>ausführen lassen. Unabhängig davon, ob Sie die Schritte nun einzeln oder zusammen ausführen, ist das Ausgabe-Fenster immer eine gute Hilfe, um die Fehler und Warnungen jeder Aktion direkt lokalisieren zu können. <\/p>\n Mit einem Doppelklick auf eine Meldung wechseln Sie direkt zum nicht migrierten Objekt. Im oberen Bereich des SSMA sehen Sie dann den SQL-Code des Access-Objekts (DDL Anweisungen) und im unteren den SQL-Code des SQL Server-Objekts (siehe Bild 9).<\/p>\n Bild 9: Anhand der unterschiedlichen Codes können Sie nun ermitteln, warum das Objekt nicht migriert wurde.<\/p>\n Diese Darstellung funktioniert natürlich auch bei den fehlerfrei migrierten Objekten. Dort sehen Sie dann, wie der SQL-Code der Access-Objekte auf dem SQL Server umgesetzt wurde.<\/p>\n Die Objekte, die nicht migriert werden konnten, sind auch ohne das Ausgabe-Fenster zu erkennen. Sie sind in der Baumansicht der Access-Objekte mit einem roten Symbol gekennzeichnet. Für jedes einzelne Objekt – egal ob migriert oder fehlerhaft – steht ein eigener Bericht zur Verfügung. Sie müssen nur das Objekt markieren und auf den Menübefehl Create Report <\/b>klicken. Als Ergebnis erhalten Sie einen ausführlichen interaktiven Bericht über die Migration des Objekts.<\/p>\n Der Vorteil von SSMA: Sie können die Migration an jedem Punkt stoppen und beenden – und bei Gelegenheit das Projekt wieder öffnen und die Migration fortsetzen. <\/p>\n Die Aufteilung der einzelnen Migrationsschritte, die Vielzahl der Konfigurationsmöglichkeiten und insbesondere die ausführliche Berichterstellung lassen den Upsizing-Assistenten von Access neben dem SSMA etwas verblassen. Der Upsizing-Assistent wird immer komplett ausgeführt; eine Aufteilung in einzelne Schritte wie Schemaerstellung und Datenmigration ist nicht möglich. <\/p>\n Dagegen bietet der Upsizing-Assistent immer noch die Möglichkeit, nach der Migration die Access-Applikation zu ändern. Die Tabellen können entweder direkt in die MDB verlinkt oder es kann eine ADP erzeugt werden.<\/p>\n Einen Teil dieser Anforderungen kann auch der SSMA abdecken: über das Kontextmenü des Knotens Tabellen <\/b>in der Baumansicht Access-Metadaten <\/b>stehen Ihnen die Befehle Link <\/b>und Unlink <\/b>zur Verfügung, mit denen Sie die SQL Server-Tabellen in die MDB verknüpfen beziehungsweise bestehende Verknüpfungen wieder löschen können. <\/p>\n Eine Migration macht noch keine Datenbank-Applikation, egal ob die Migration von Hand, durch den Upsizing-Assistenten oder durch den SSMA ausgeführt wurde. Es wurden dabei lediglich Access-Tabellen zu SQL Server-Tabellen migriert und die Daten übernommen; im besten Fall wurden sogar einige Abfragen zu Sichten beziehungsweise gespeicherten Prozeduren migriert. <\/p>\n Das heißt jedoch nicht, dass die Tabellen beziehungsweise Abfragen 1:1 umgesetzt wurden. Die Tabellen des SQL Servers unterscheiden sich in den genutzten Datentypen von den Access-Tabellen und bestimmte Tabellenattribute wurden eventuell nicht oder in einer anderen Form umgesetzt. Bei den Abfragen wird der Unterschied am deutlichsten. Nur die einfachsten Abfragen werden migriert und sind zudem noch oft in veränderter Form wiederzufinden. Die Datenmigration allein ist also kein Garant dafür, dass die migrierte Datenbank-Applikation nun schneller als die alte Access-Applikation läuft. In manchen Fällen ist die neue Applikation sogar langsamer. <\/p>\n Welche änderungen bei den Tabellen und Abfragen vorgenommen werden, warum einige Objekte nicht migriert werden können und wie Sie diese trotzdem auf den SQL Server bekommen, sowie Informationen über die Optimierung Ihrer migrierten Access-Applikation für die Welt der Datenbankserver lesen Sie in einer der folgenden Ausgaben von Access im Unternehmen<\/b>.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662007,66052007,44000029,44000022],"tags":[],"class_list":["post-55000490","post","type-post","status-publish","format-standard","hentry","category-662007","category-66052007","category-Abfragetechnik_und_SQL","category-SQL_Server_und_Co"],"yoast_head":"\n\nMöglichkeiten<\/h2>\n
Vorbereitungen<\/h2>\n
\n\n\n
\n \n \n \n Migration mit dem Upsizing-Assistenten<\/h2>\n
\n ![\"pic001.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic001_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic002.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic002_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic003.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic003_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic004.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic004_opt.jpeg\")
\n <\/div>\n\nMigration mit dem SSMA<\/h2>\n
.com\/downloads\/details.aspxfamilyid=d842
f8b4-c914-4ac7-b2f3-d25fff4e24fb&dis
playlang=en <\/b>kostenfrei heruntergeladen werden. Nach der Installation müssen Sie den SSMA noch lizenzieren. Auch die Lizenzierung ist kostenfrei.<\/p>\n\n ![\"pic005.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic005_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic006.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic006_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic007.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic007_opt.jpeg\")
\n <\/div>\n\n\n ![\"pic008.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic008_opt.jpeg\")
\n <\/div>\n\n
Bericht der Migration<\/span><\/b><\/p>\n<\/p><\/div>\n\n ![\"pic009.TIF\"](\"..\/fileadmin\/_temp_\/2007_05\/MigrationVonAccessZumSQLServer-web-images\/pic009_opt.jpeg\")
\n <\/div>\n\n
Gegenüberstellung der SQL-Codes<\/span><\/b><\/p>\n<\/p><\/div>\nZusammenfassung und Ausblick<\/h2>\n