Möchtest Du den gesamten Artikel lesen? Und vielleicht sogar den Artikel im PDF-Format und die Beispieldateien herunterladen? Dann hole Dir den Artikel gleich hier - völlig kostenlos!
Für die Migration der Tabellen einer Access-Datenbanken in eine SQL Server-Datenbank erledigt man am einfachsten mit einem von Microsoft bereitgestellten Tool namens SQL Server Migration Assistant. Diesem übergeben wir den Namen der zu migrierenden Datenbank, wählen die Tabellen und Abfragen aus, die zum SQL Server übertragen werden sollen und starten dann die Migration. Dies überträgt legt eine neue Datenbank im SQL Server an und überträgt die gewählten Tabellen und Abfragen von Access zum SQL Server. Mit dem SQL Server Migration Assistant können wir außerdem direkt Tabellenverknüpfungen zu den neu erstellten Tabellen in der Access-Datenbank anlegen, sodass wir grundsätzlich direkt mit der Access-Anwendung weiterarbeiten können – mit dem Unterschied, dass die Daten nun nicht mehr aus den Access-Tabellen kommen, sondern vom SQL Server. In diesem Artikel zeigen wir die grundlegende Verwendung des SQL Server Migration Assistants, wobei wir erst einmal eine Datenbank verwenden, deren Tabellen und Felder sich ohne größere Probleme zum SQL Server übertragen lassen.
SQL Server Migration Assistant herunterladen und installieren
Die jeweils aktuelle Version des SQL Server Migration Assistant finden wir, wenn wir im Internet nach genau diesen Schlüsselwörtern suchen.
Wir landen dann beispielsweise auf einer Seite wie der aus Bild 1. Hier klicken wir nicht etwa auf SQL Server Migration Assistant for Access, sondern scrollen weiter nach unten, wo wir unter Downloads den Eintrag SSMA for Access finden.
Bild 1: Download des SQL Server Migration Assistant
Auf der nun erscheinenden Seite klicken wir auf Download. Die Sprache können wir nicht ändern, da der SSMA nur in Englisch verfügbar ist.
Richtige Bitness auswählen
Es erscheint ein Popup, das die verschiedenen Versionen auflistet (siehe Bild 2). Hier gibt es zum Beispiel zwei verfügbare Versionen (9.5 und 10.4), die jeweils für 32-Bit und 64-Bit verfügbar sind.
Bild 2: Auswahl der richtigen Version
Hier sollten wir die aktuellere Version wählen. Viel wichtiger ist jedoch, die richtige Bitness zu selektieren. Ob wir die 32-Bit-Version (erkennbar am Zusatz x86) oder die 64-Bit-Version wählen (ohne Zusatz), hängt nicht etwa von der Bitness des installierten Betriebssystems zusammen, sondern von der Bitness der Access-Installation.
Zur Sicherheit prüfen wir also, ob unsere Access-Version in der 32-Bit- oder in der 64-Bit-Version installiert ist. Das können wir beispielsweise über die Benutzeroberfläche von Access herausfinden. Dazu klicken wir in neueren Access-Versionen im Ribbon auf den Reiter Datei und im nun erscheinenden Bereich links auf Konto.
Rechts sehen wir nun eine Schaltfläche namens Info zu Access. Damit öffnen wir den Dialog aus Bild 3. Oben sehen wir nun entweder den Text 32 Bit oder 64 Bit. In diesem Fall haben wir es mit einem 32-Bit-Access zu tun, also installieren wir den SQL Server Migration Assistant mit dem Zusatz x86.
Bild 3: Ermitteln der Bitness der Access-Installation
Migration vorbereiten
Für die erste Migration könnte man eine ganze Reihe von Bedingungen direkt in den Tabellen der Access-Datenbank prüfen – ob die Beziehungen korrekt gesetzt sind, nur gültige Namen für Tabellen, Felder, Indizes und so weiter gesetzt sind und ob nur Datentypen verwendet werden, die der SQL Server auch unterstützt.
Wir können aber auch einfach eine Migration starten und abwarten, welche Fehler, Warnungen und Hinweise uns der SQL Server Migration Assistant liefert. Diese können wir dann in Access korrigieren und eine erneute Migration starten.
Wenn wir bei der Migration gleich Tabellenverknüpfungen zur Access-Datenbank hinzufügen wollen, sparen wir uns eine Menge nachträglicher Arbeit. Dies erledigt folgende Aufgaben:
- Die vorhandenen lokalen Tabellen werden nach einem bestimmten Schema umbenannt.
- Es werden Tabellenverknüpfungen zu den migrierten Tabellen angelegt.
In der Regel werden wir nach der initialen Migration allerdings Fehler, Warnungen und Hinweise auf Probleme erhalten, die wir gegebenenfalls erst in der originalen Access-Datenbank anpassen wollen, um anschließend in einer weiteren Migration die Tabellen mit weniger oder möglichst sogar ohne Fehlermeldungen zum SQL Server zu übertragen.
Dazu ein kleiner Vorgriff: Wir könnten dann auf die Idee kommen, die vom SQL Server Migration Assistant zur Access-Datenbank hinzugefügten Tabellenverknüpfungen einfach zu löschen und den umbenannten lokalen Tabellen einfach wieder den Originalnamen zuzuweisen.
Wenn wir diese Datenbank dann erneut mit dem SQL Server Migration Assistant migrieren wollen, wird dieser aber überraschenderweise keine Tabellen in der Access-Datenbank mehr finden, die sich migrieren lassen.
Der Grund dafür ist, dass der SSMA die Originaltabellen nicht nur umbenennt, sondern auch verschiedene Eigenschaften einstellt, mit denen der SSMA bei erneuter Migration erkennen kann, welche Tabellen bereits migriert wurden.
Wir könnten nun zwar per VBA-Code nicht nur die bereits migrierten Tabellen wieder mit den Originalnamen versehen, sondern auch die vom SSMA hinzugefügten Eigenschaften löschen, damit diese erneut migriert werden können.
Es ist aber wesentlich einfacher, vor der Migration eine Kopie der zu migrierenden Datenbank zu erstellen. Wenn wir dann nach der ersten Migration feststellen, dass wir noch Änderungen an den Tabellen der Access-Datenbank vornehmen wollen, damit diese im zweiten Durchlauf ohne Fehler, Warnungen und Hinweise migriert werden kann, können wir einfach die bereits migrierte Version verwerfen und mit der Kopie erneut starten.
Migrieren der Access-Datenbank
Damit starten wir die erste Migration. Die Beispieldatenbank haben wir so gestaltet, dass zumindest keine Fehler bei der Migration gemeldet werden. Welche Fehler, Warnungen und Hinweise bei der Migration auftreten können und wie wir diese beheben, werden wir uns aus Platzgründen ohnehin nicht in diesem Artikel ansehen.
Wenn wir den SQL Server Migration Assistant gestartet haben, zeigt dieser standardmäßig gleich den Migration Wizard an (siehe Bild 4), der uns die verschiedenen Schritte der Migration vorstellt. Hier können wir außerdem festlegen, ob der Wizard beim nächsten Start des SQL Server Migration Assistants erneut aufgerufen werden soll. Diese Einstellung behalten wir zunächst bei. Wir können sie aber auch deaktivieren und den Wizard bei späteren Starts des SSMA über den Menüpunkt File|Migration Wizard manuell aufrufen.
Bild 4: Start des SQL Server Migration Assistants
Im zweiten Schritt definieren wir die Daten des Migrationsprojekts. Hier geben wir einen Namen an und können den Pfad der zu speichernden Projektdatei festlegen (siehe Bild 5).
Bild 5: Angabe eines Projektnamens
Außerdem legen wir hier fest, zu welcher SQL Server-Version wir die Access-Datenbank migrieren wollen – hier SQL Server 2022.
SQL Server-Version ermitteln
Wenn Du nicht sicher bist, welche SQL Server-Version Du verwendest, kannst Du das im SQL Server Management Studio herausfinden. Dazu klickst Du im Objekt-Explorer mit der rechten Maustaste auf das oberste Element für die aktuelle Verbindung und wählst im Kontextmenü den Eintrag Neue Abfrage aus.
Hier gibst Du den folgenden Befehl ein und führst diesen mit der Taste F5 aus:
SELECT @@Version
Dies liefert das Ergebnis aus Bild 6 – in diesem Fall wird also der SQL Server in der Version 2022 verwendet, die wir auch im SSMA auswählen sollten.
Bild 6: Ermitteln der SQL Server-Version
Im SSMA klicken wir nun auf Next und landen im nächsten Schritt, in dem wir über die Schaltfläche Add Databases die Access-Datenbank auswählen, deren Tabellen wir zum SQL Server migrieren wollen. Diese erscheint anschließend in der Liste der hinzuzufügenden Access-Datenbanken.
Hier ist zu erkennen, dass wir durchaus auch die Tabellen mehrerer Access-Datenbanken gleichzeitig in eine SQL Server-Datenbank migrieren können. Das ist zum Beispiel sinnvoll, wenn wir ein Frontend nutzen, das mit den Tabellen aus mehreren Access-Backends verknüpft ist, die alle in einer neuen SQL Server-Datenbank landen sollen. In diesem Fall wollen wir jedoch nur eine Access-Datenbank migrieren.
Lokale und verknüpfte Access-Tabellen
An dieser Stelle kommt oft die Frage auf, wie man mit dem Fall umgeht, dass eine Frontend-Datenbank verwendet wird, die ihre Daten über Tabellenverknüpfungen zu einer weiteren, als Backend verwendeten Access-Datenbank bezieht.
Hier hat man zwei Möglichkeiten:
- Man gibt die Frontend-Datenbank als Quelle für die Migration an, wodurch man sowohl lokale Tabellen als auch verknüpfte Tabellen migrieren kann.
- Oder man gibt die Backend-Datenbank als Quelle für die Migration an, wodurch nur die Tabellen aus der Backend-Datenbank zur Migration herangezogen werden können.
Welche Variante man wählt, hängt in erster Linie davon ab, ob der SSMA bei der Migration der Access-Datenbank direkt Tabellenverknüpfungen zu den neuen Tabellen aus der SQL Server-Datenbank anlegen soll.
Wenn wir die Variante wählen, bei der wir das Backend als Quelle für die Tabellen angeben, werden die Tabellenverknüpfungen auch automatisch in der Backenddatenbank angelegt. Das ist weniger sinnvoll, da wir diese ja im Frontend benötigen.
Wir würden also an dieser Stelle normalerweise die Frontenddatenbank mit dem Tabellenverknüpfungen zur Backenddatenbank auswählen.
Der SQL Server Migration Assistant erkennt dies automatisch und migriert dann die verknüpften Tabellen aus dem Backend. Wenn wir die Option zum automatischen Erstellen von Tabellenverknüpfungen zu den Tabellen in der zu erstellenden SQL Server-Datenbank wählen, benennt der SSMA die Tabellenverknüpfungen zu den Tabellen des Access-Backends um und ersetze diese durch die Verknüpfungen zu den Tabellen der SQL Server-Datenbank.
Tabellen für die Migration auswählen
Im SQL Server Migration Assistant gehen wir nun zum nächsten Schritt, in dem wir die zu migrierenden Objekte der Access-Datenbank auswählen können (siehe Bild 7). Unter dem Element Databases finden wir die zuvor auswählte Datenbank. Erweitern wir die Knoten, sehen wir dort alle Tabellen der zu migrierenden Datenbank. Diese werden automatisch alle auswählt, sodass wir nur eventuell nicht zu migrierende Tabellen abzuwählen brauchen.
Bild 7: Auswählen der zu migrierenden Tabellen
Sollten hier keine Tabellen erscheinen, ist vermutlich das passiert, was wir weiter oben beschrieben haben: Du hast dann bereits eine Migration durchgeführt und versuchst nun, die Tabellen einer bereits migrierten Datenbank erneut im SSMA auszuwählen. Das funktioniert wie beschrieben nicht, da einmal migrierte Tabellen mit entsprechenden Eigenschaften markiert werden, damit diese nicht erneut migriert werden können.
SQL Server und Zieldatenbank festlegen
Im vorliegenden Fall können wir jedoch alle Tabellen migrieren, daher klicken wir auf Next und landen im nächsten Dialog (siehe Bild 8). Hier wählen wir zuerst den SQL Server aus, in dem wir die neue Datenbank anlegen wollen. Den Port brauchen wir normalerweise nicht einzustellen, wenn dieser nicht geändert wurde. Außerdem geben wir hier den Namen der zu erstellenden Datenbank an, der automatisch mit dem Namen der zu migrierenden Datenbank vorbelegt wird.
Bild 8: Festlegen des Ziel-SQL Servers
Schließlich geben wir noch an, mit welcher Authentifizierungsmethode wir uns zum Migrieren der Datenbank am SQL Server anmelden wollen. Diese hängt davon ab, wie Du Dich generell am SQL Server anmeldest. Wenn Du SQL Server Authentication auswählst, musst Du noch den Benutzernamen und das Kennwort für den Benutzer angeben, unter dem Du Zugriff auf den SQL Server hast.
Außerdem gibst Du noch an, ob die Verbindung verschlüsselt erfolgen soll (Encrypt Connection) und ob Du dem Server-Zertifikat vertrauen möchtest (Trust Server Certificate). Beide können wir in der Regel aktiviert lassen, gegebenenfalls führt das Weglassen einer der beiden Optionen sogar dazu, dass keine Verbindung aufgebaut werden kann. Richte Dich hier nach den Einstellungen, die Du verwendest, wenn Du Dich über das SQL Server Management Studio am SQL Server anmeldest.
Klicken wir nun auf Next, erscheint die Meldung aus Bild 9. Hier bestätigen wir, dass die Datenbank angelegt werden soll. Wenn wir nicht zum ersten Mal migrieren und die Datenbank bereits vorhanden ist, fragt diese Meldung, ob eine vorhandene Datenbank gleichen Namens überschrieben werden soll.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo