Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Wer schnell die Tabellen einer Access-Datenbank zum SQL Server migrieren möchte, kann dazu ein kostenloses Tool von Microsoft nutzen: Den SQL Server Migration Assistant, in diesem Fall in der Ausführung für Access. Wie wir die Tabelle einer Access-Datenbank zum SQL Server übertragen und gleichzeitig auch noch die passenden Verknüpfungen für den Zugriff auf diese Datenbank erstellen, zeigen wir in diesem Beitrag. Dabei nutzen wir die schnellste zur Verfügung stehende Methode, nämlich den Migration Wizard, ein Assistent im Assistenten. Im besten Fall kann man danach direkt von der Access-Datenbank auf die Daten im SQL Server-Backend zugreifen. Gegebenenfalls sind noch Vor- und Nacharbeiten erforderlich, um die kümmern wir uns jedoch in eigenen Beiträgen.
Voraussetzungen
Wenn Sie die Beispiele dieses Beitrags ausprobieren möchten, benötigen Sie eine Installation des SQL Servers mit der Möglichkeit, dort eine neue Datenbank anzulegen, das SQL Server Management Studio, um das Ergebnis zu betrachten, eine eigene Access-Datenbank oder die Beispieldatenbank aus dem Download zu diesem Artikel als Testmaterial.
Außerdem wollen wir den SQL Server Migration Assistant für Access herunterladen, den wir beispielsweise über Google mit den Suchbegriffen sql server migration assistant for access finden sollten.
Damit landen wir schnell auf der Microsoft-Seite mit dem Download dieses kostenlosen Tools, das wir hier direkt herunterladen können.
Beim Download taucht gegebenenfalls ein Dialog auf, der nach der gewünschten Version fragt. Hier stehen die 32-Bit- und die 64-Bit-Variante zur Verfügung. Welche Sie wählen, hängt von der Office-Version ab, die auf dem Zielsystem installiert ist, nicht von der Windows-Version. Wir haben aktuell noch Office in der 32-Bit-Version installiert, also verwenden wir den Download SSMAforAccess_9.5.0_x86.msi (siehe Bild 1).
Bild 1: Auswahl der gewünschten Version des SSMA
Nachdem Download führen wir die .msi-Datei aus und installieren so den SQL Server Migration Assistant for Access, von nun an kurz SSMA genannt.
Erster Start des SSMA
Nach dem Start erscheint der SSMA bildschirmfüllend und bietet einen Migration Wizard zur Unterstützung an (siehe Bild 2). Diesen können wir per Klick auf die Option Launch this Wizard at Startup für zukünftige Starts deaktivieren, wenn wir diesen nicht mehr nutzen wollen.
Bild 2: Der Migrations-Assistent
Vorerst wollen wir diesen Wizard jedoch nutzen, um eine schnelle, erste Migration durchzuführen.
Für einen Überblick über die anstehenden Aufgaben bietet es sich an, sich den Ablauf einmal anzusehen, der wie folgt aussieht:
- Erstellen eines neuen SSMA-Projekts
- Hinzufügen von Access-Datenbankdateien zum Migrationsprojekt
- Auswahl der zu migrierenden Objekte
- Verbinden zum SQL Server oder zur Azure Datenbank
- Optional: Verknüpfen der migrierten Tabellen
- Übertragen der Objekte und Migrieren der Daten
Wir führen die Schritte einmal anhand einer kleinen Beispieldatenbank durch.
Diese Beispieldatenbank stellen wir im Beitrag Datenmodell Mitarbeiterverwaltung (www.access-im-unternehmen.de/19) vor.
Erstellen des Migrationsprojekts
Im ersten Schritt des Migration Wizard finden wir die Eingabemöglichkeiten aus Bild 3 vor. Dieser erwartet die Eingabe von drei Informationen. Die erste ist der Name, unter dem wir die neue Migration speichern wollen. Hier geben wir beispielsweise Migration_Mitarbeiterverwaltung an. Unter Location legen wir fest, in welchem Verzeichnis die Projektdatei gespeichert wird.
Bild 3: Schritt 1 des Migration Wizard: Erstellen eines neuen Projekts
Der Dateiname ergibt sich aus dem Namen für die Migration und die Dateiendung .ssma. Schließlich wählen wir noch die Version des SQL Server aus, der als Ziel der Migration dienen soll. Damit können wir mit einem Klick auf die Schaltfläche Next den ersten Schritt abschließen.
Hinzufügen von Access-Datenbankdateien zum Migrationsprojekt
Dieser Schritt ist nur in unserem Fall schnell zu erledigen, denn wir haben lediglich eine einzige Datenbankdatei, in der sich die zu migrierenden Tabellen befinden.
Wir klicken also auf Add Databases und wählen im folgenden Dateiauswahldialog die Datenbank Mitarbeiterverwaltung.accdb aus. Damit können wir in diesem Fall direkt zum nächsten Schritt fortfahren (siehe Bild 4).
Bild 4: Schritt 2 des Migration Wizard: Hinzufügen der Datenbank, deren Tabellen migriert werden sollen
Auswahl der Datenbankdatei bei aufgeteilten Datenbanken
Etwas komplizierter wird es jedoch, wenn wir nicht mit einer einzigen Datenbankdatei arbeiten, sondern wenn dieser bereits aufgeteilt ist – in ein Frontend und ein Backend oder sogar mehrere Frontends, die auf das Backend zugreifen. Es gibt auch noch kompliziertere Konstellationen mit mehreren Frontends und mehreren Backends, aber auf diesen Fall wollen wir an dieser Stelle nicht eingehen.
Wenn wir eine Anwendung mit Datenbankfrontend und -backend verwenden, enthält das Frontend in der Regel die Anwendungslogik (also Abfragen, Formulare, Berichte und VBA-Code) sowie Tabellenverknüpfungen, über die man auf die Tabellen im Backend zugreifen kann.
Im Backend hingegen befinden sich ausschließlich die Tabellen der Anwendung. Es kann für spezielle Aufgaben auch noch Tabellen im Frontend geben, aber diese würde man, wenn man sie im Frontend-Backend-Szenario nicht in das Backend überführt hat, vermutlich auch nicht in die SQL Server-Datenbank geben.
Intuitiv würde man nun möglicherweise die Backend-Datenbank als Quelle für die Migration der Datenbank zum SQL Server angeben.
Wenn wir allerdings im gleichen Schritt die Funktion des Migration Wizard nutzen wollen, um die Tabellenverknüpfungen hinzuzufügen, ergibt dies keinen Sinn: Die Tabellenverknüpfungen für den Zugriff auf die Tabellen im SQL Server würden dann nämlich im Backend der Access-Datenbank landen.
Die zweite Option ist, dennoch das Backend als Quelle für die Migration zu verwenden und anschließend die Tabellenverknüpfungen zum SQL Server auf eine andere Weise als mit dem Migration Wizard zu erledigen.
Bleiben noch zwei Möglichkeiten: Wir geben beide Datenbankdateien an oder wir geben nur die Frontenddatenbank als Quelle für die Migration an.
Wir betrachten erst den letzteren Fall: Hier würde der Migration Wizard über die Tabellenverknüpfungen im Frontend auf die Tabellen im Backend zugreifen, diese migrieren, und auf Wunsch die Tabellenverknüpfungen auf den SQL Server zum Frontend hinzufügen.
Dabei würden die zuvor auf die Tabellen im Access-Backend verweisenden Tabellenverknüpfungen umbenannt werden und die neuen Tabellenverknüpfungen erhalten deren Originalnamen. Dies ist die von uns empfohlene Vorgehensweise bei vorliegendem Frontend und Backend auf Access-Basis.
Schauen wir uns noch kurz an, was passiert, wenn wir beide Datenbanken einer Frontend-Backend-Konstellation als Quelle für die Migration hinzufügen: Dann haben wir später auch die Möglichkeit, sowohl die Tabellenverknüpfungen aus dem Frontend auszuwählen als auch die Originaltabellen aus dem Backend.
Wenn wir beide auswählen, geschieht logischerweise Folgendes: Die Tabellen aus der zuerst angegebenen Quelldatenbank werden in den SQL Server geschrieben. Für die gleichnamigen Tabellen der zweiten Datenbank fragt der Migration Wizard, ob die bereits vorhandenen Tabellen (die von der anderen Quelle) überschrieben werden sollen.
Es landet also ohnehin nur eine Kopie der jeweiligen Tabelle in der SQL Server-Datenbank.
Dafür erhalten wir in beiden Quelldatenbanken, also im Frontend und im Backend, jeweils die Verknüpfungen auf diese Tabellen.
Wie gesagt: In diesem Kontext macht es keinen Sinn, Frontend und Backend als Datenquelle anzugeben.
Zusammengefasst:
- Wenn es ohnehin nur eine Access-Datenbankdatei gibt, wird diese als Quelle angegeben.
- Wenn die Datenbank auf Frontend- und Backenddatei aufgeteilt ist, geben wir die Frontend-Datenbank als Quelle für den Migration Wizard an.
Auswahl der zu migrierenden Objekte
Im folgenden Schritt zeigt der Migration-Wizard auf der linken Seite die gewählten Datenbanken und die enthaltenen Objekte an. Dort werden nicht nur Tabellen, sondern, falls vorhanden, auch Abfragen angezeigt (siehe Bild 5).
Bild 5: Schritt 3 des Migration Wizard: Auswahl der zu migrierenden Objekte
In diesem Fall wollen wir nur die Tabellen migrieren. Abfragen kann man zwar auch direkt in entsprechende SQL Server-Objekte migrieren, in der Regel enthalten Access-Abfragen jedoch Elemente, die nicht SQL Server-kompatibel sind und viel Nacharbeit erfordern.
Wir wollen uns daher an dieser Stelle auf die Migration der Tabellen beschränken.
Wir haben hier die Gelegenheit, entweder einfach alle Tabellen zu migrieren oder diese noch manuell aus- oder abzuwählen. Gegebenenfalls befinden sich unter den Tabellen solche, die nur temporär und lokal genutzt werden sollen und die wir von der Migration ausklammern sollten – dann gibt es an dieser Stelle die Gelegenheit dazu.
In diesem Fall übernehmen wir einfach alle Tabellen und springen mit einem Klick auf die Next-Schaltfläche zum nächsten Schritt.
Verbinden zum SQL Server oder zur Azure Datenbank
Im nächsten Schritt legen wir verschiedene Informationen fest, mit denen wir auf die Zieldatenbank eingehen (siehe Bild 6):
Bild 6: Schritt 4 des Migration Wizard: Eingeben von Informationen zur Zieldatenbank
- Server name: Gibt die IP-Adresse oder den Namen des SQL Servers an, gegebenenfalls gefolgt vom Namen einer benannten Instanz.
- Server port: Gibt den Server-Port an, hier kann man in der Regel den Wert [default] beibehalten.
- Database: Gibt den Namen der Datenbank an. Bei der erstmaligen Migration können wir den Namen einer bereits vorhandenen Datenbank als Ziel angeben oder wir legen den Namen der zu erstellenden Datenbank fest.
- Authentication: Gibt die Authentifizierungsmethode an. Windows Authentication wird verwendet, wenn man sich auf dem gleichen Rechner oder in der gleichen Domäne wie der SQL Server befindet, ansonsten wird meist SQL Server Authentication genutzt. Die beiden folgenden Textfelder werden nur freigeschaltet, wenn man SQL Server Authentication wählt, denn sonst erfolgt die Anmeldung über das Windows-Konto des aktuellen Benutzers.
- User name: Nimmt bei SQL Server-Authentifizierung den Benutzernamen entgegen, der im SQL Server definiert sein muss.
- Password: Nimmt bei Verwendung der SQL Server-Authentifizierung das Kennwort entgegen.
- Encrypt Connection: Gibt an, ob die Verbindung verschlüsselt werden soll. Wird diese Option aktiviert, erscheint noch eine weitere Option namens Trust Server Certificate (siehe Bild 7).
Bild 7: Einstellungen für Verschlüsselung
Beim Mausklick auf die Schaltfläche Next erscheint eine Meldung mit der Rückfrage, ob die angegebene Datenbank, die noch nicht im SQL Server enthalten ist, neu angelegt werden soll, was wir mit einem Klick auf die Schaltfläche Ja bestätigen (siehe Bild 8).
Bild 8: Frage, ob die Datenbank neu erstellt werden soll
Optional: Verknüpfen der migrierten Tabellen
Einen Schritt später fragt der Migration Wizard noch, ob die Tabellen direkt in die Quelltabelle eingebunden werden sollen (siehe Bild 9). Da wir die Datenbank nach der Migration möglichst direkt mit den SQL Server-Tabellen verwenden wollen, aktivieren wir die entsprechende Option.
Bild 9: Schritt 5 des Migration Wizard: Angabe, ob die Tabellen direkt verknüpft werden sollen
Übertragen der Objekte und Migrieren der Daten
Im nächsten Schritt startet die Migration. Dabei werden zuerst, wie im Bereich Convert selected objects, die zu migierenden Objekte konvertiert (siehe Bild 10).
Bild 10: Migration: Konvertieren der zu migrierenden Objekte
Beim Konvertieren werden meist direkt ein paar Fehler, Warnungen und Hinweise produziert.
Dann folgt der nächste Schritt, wo die konvertierten Elemente in die SQL Server-Datenbank geladen werden, was bedeutet, dass die entsprechenden Elemente in der Datenbank angelegt werden (Bereich Load converted objects into the target database). Am Ende dieses Schrittes erscheint der Dialog Synchronize with the Database (siehe Bild 11).
Bild 11: Zuordnung der zu erstellenden Tabellen festlegen
Dieser zeigt auf der rechten Seite alle zu migrierenden Tabellen an, auf der rechten Seite steht überall der Eintrag [Not Found].
Das ist kein Problem, sondern eher erwartungsgemäß. Erst wenn wir eine Datenbank migrieren, die bereits im SQL Server vorhanden ist, werden hier gegebenenfalls gleichnamige Tabellen zur Zuordnung angeboten.
Also behalten wir die Einstellungen so bei und klicken auf OK.
Danach startet das Anlegen der Objekte in der Zieldatenbank (siehe Bild 12). Auch hier gibt es gegebenenfalls wieder Fehler et cetera.
Bild 12: Anlegen der Datenbankobjekte in der Zieldatenbank
Schließlich folgt die Migration der Daten aus den Originaltabellen in die Zieltabellen und direkt im Anschluss, sofern wir dies im Wizard aktiviert haben, die Erstellung von Tabellenverknüpfungen (siehe Bild 13).
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