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.<\/b><\/p>\n
Voraussetzungen<\/h2>\n
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.<\/p>\n
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 <\/b>finden sollten.<\/p>\n
Damit landen wir schnell auf der Microsoft-Seite mit dem Download dieses kostenlosen Tools, das wir hier direkt herunterladen können.<\/p>\n
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 <\/b>(siehe Bild 1).<\/p>\n
![\"Auswahl](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_001.png\")
<\/p>\n
Bild 1: Auswahl der gewünschten Version des SSMA<\/span><\/b><\/p>\n Nachdem Download führen wir die .msi<\/b>-Datei aus und installieren so den SQL Server Migration Assistant for Access<\/b>, von nun an kurz SSMA <\/b>genannt.<\/p>\n Nach dem Start erscheint der SSMA bildschirmfüllend und bietet einen Migration Wizard<\/b> zur Unterstützung an (siehe Bild 2). Diesen können wir per Klick auf die Option Launch this Wizard at Startup <\/b>für zukünftige Starts deaktivieren, wenn wir diesen nicht mehr nutzen wollen.<\/p>\n Bild 2: Der Migrations-Assistent<\/span><\/b><\/p>\n Vorerst wollen wir diesen Wizard jedoch nutzen, um eine schnelle, erste Migration durchzuführen.<\/p>\n Für einen Überblick über die anstehenden Aufgaben bietet es sich an, sich den Ablauf einmal anzusehen, der wie folgt aussieht:<\/p>\n Wir führen die Schritte einmal anhand einer kleinen Beispieldatenbank durch.<\/p>\n Diese Beispieldatenbank stellen wir im Beitrag Datenmodell Mitarbeiterverwaltung <\/b>(www.access-im-unternehmen.de\/19<\/b>) vor.<\/p>\n Im ersten Schritt des Migration Wizard <\/b>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 <\/b>an. Unter Location <\/b>legen wir fest, in welchem Verzeichnis die Projektdatei gespeichert wird.<\/p>\n Bild 3: Schritt 1 des Migration Wizard: Erstellen eines neuen Projekts<\/span><\/b><\/p>\n Der Dateiname ergibt sich aus dem Namen für die Migration und die Dateiendung .ssma<\/b>. 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 <\/b>den ersten Schritt abschließen.<\/p>\n 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.<\/p>\n Wir klicken also auf Add Databases <\/b>und wählen im folgenden Dateiauswahldialog <\/b>die Datenbank Mitarbeiterverwaltung.accdb <\/b>aus. Damit können wir in diesem Fall direkt zum nächsten Schritt fortfahren (siehe Bild 4).<\/p>\n Bild 4: Schritt 2 des Migration Wizard: Hinzufügen der Datenbank, deren Tabellen migriert werden sollen<\/span><\/b><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Intuitiv würde man nun möglicherweise die Backend-Datenbank als Quelle für die Migration der Datenbank zum SQL Server angeben.<\/p>\n Wenn wir allerdings im gleichen Schritt die Funktion des Migration Wizard <\/b>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.<\/p>\n 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.<\/p>\n Bleiben noch zwei Möglichkeiten: Wir geben beide Datenbankdateien an oder wir geben nur die Frontenddatenbank als Quelle für die Migration an.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Es landet also ohnehin nur eine Kopie der jeweiligen Tabelle in der SQL Server-Datenbank.<\/p>\n Dafür erhalten wir in beiden Quelldatenbanken, also im Frontend und im Backend, jeweils die Verknüpfungen auf diese Tabellen.<\/p>\n Wie gesagt: In diesem Kontext macht es keinen Sinn, Frontend und Backend als Datenquelle anzugeben.<\/p>\n Zusammengefasst:<\/p>\n 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).<\/p>\n Bild 5: Schritt 3 des Migration Wizard: Auswahl der zu migrierenden Objekte<\/span><\/b><\/p>\n 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.<\/p>\n Wir wollen uns daher an dieser Stelle auf die Migration der Tabellen beschränken.<\/p>\n 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.<\/p>\n In diesem Fall übernehmen wir einfach alle Tabellen und springen mit einem Klick auf die Next<\/b>-Schaltfläche zum nächsten Schritt.<\/p>\n Im nächsten Schritt legen wir verschiedene Informationen fest, mit denen wir auf die Zieldatenbank eingehen (siehe Bild 6):<\/p>\n Bild 6: Schritt 4 des Migration Wizard: Eingeben von Informationen zur Zieldatenbank<\/span><\/b><\/p>\n Bild 7: Einstellungen für Verschlüsselung<\/span><\/b><\/p>\n<\/ul>\n Beim Mausklick auf die Schaltfläche Next <\/b>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 <\/b>bestätigen (siehe Bild 8).<\/p>\n Bild 8: Frage, ob die Datenbank neu erstellt werden soll<\/span><\/b><\/p>\n 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.<\/p>\n Bild 9: Schritt 5 des Migration Wizard: Angabe, ob die Tabellen direkt verknüpft werden sollen<\/span><\/b><\/p>\n Im nächsten Schritt startet die Migration. Dabei werden zuerst, wie im Bereich Convert selected objects<\/b>, die zu migierenden Objekte konvertiert (siehe Bild 10).<\/p>\n Bild 10: Migration: Konvertieren der zu migrierenden Objekte<\/span><\/b><\/p>\n Beim Konvertieren werden meist direkt ein paar Fehler, Warnungen und Hinweise produziert. <\/p>\n 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<\/b>). Am Ende dieses Schrittes erscheint der Dialog Synchronize with the Database <\/b>(siehe Bild 11).<\/p>\n Bild 11: Zuordnung der zu erstellenden Tabellen festlegen<\/span><\/b><\/p>\n Dieser zeigt auf der rechten Seite alle zu migrierenden Tabellen an, auf der rechten Seite steht überall der Eintrag [Not Found]<\/b>.<\/p>\n 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.<\/p>\n Also behalten wir die Einstellungen so bei und klicken auf OK<\/b>.<\/p>\n Danach startet das Anlegen der Objekte in der Zieldatenbank (siehe Bild 12). Auch hier gibt es gegebenenfalls wieder Fehler et cetera.<\/p>\n Bild 12: Anlegen der Datenbankobjekte in der Zieldatenbank<\/span><\/b><\/p>\n 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).<\/p>\n Bild 13: Migrieren der Tabellendaten<\/span><\/b><\/p>\n Hier müssen wir erneut die Authentifizierung durchführen, um den Zugriff auf die Tabellen zu erlauben.<\/p>\n Damit ist dieser Teil der Migration abgeschlossen (siehe Bild 14).<\/p>\n Bild 14: Abschluss der Migration<\/span><\/b><\/p>\n Damit schauen wir uns nun die Fehler, Warnungen und Hinweise der verschiedenen Phasen der Migration an. Zuerst klicken wir auf den Link im Bereich Convert selected objects<\/b>. Dies liefert einen Dialog, der die Meldungen auflistet und weitere Informationen dazu liefert (siehe Bild 15).<\/p>\n Bild 15: Untersuchen der Fehler, Warnungen und Hinweise<\/span><\/b><\/p>\n Klicken wir doppelt auf einen der Einträge, wird das Element der Quelldatenbank markiert, der für die Meldung verantwortlich ist. Eine Zusammenfassung der gängigsten Fehler, Warnungen und Hinweise schauen wir uns noch in einem späteren Beitrag an.<\/p>\n Um die Übersicht bei vielen Meldungen zu erhöhen, können wir durch einen Klick auf die entsprechenden Schaltflächen Errors<\/b>, Warnings <\/b>und Informationen <\/b>ein- und ausblenden. Auf die gleiche Weise können wir die Meldungen für die übrigen Bereiche betrachten und den Dialog dann schließen.<\/p>\n Nun finden wir das Hauptfenster des SQL Server Migration Assistant mit allen bei der Migration angefallen Daten vor (siehe Bild 16).<\/p>\n Bild 16: Der SQL Server Migration Assistant nach der Migration<\/span><\/b><\/p>\n Die oberen Bereiche auf der linken und der rechten Seite enthalten einige Informationen rund um die Elemente der Quell- und der Zieldatenbank. Interessant sind jedoch zunächst die Ergebnisse im unteren Bereich.<\/p>\n Hier sehen wir nicht nur die Fehler, Warnungen und Informationen, die wir bereits unmittelbar nach der Migration zu sehen bekommen haben, sondern auch noch eine Auflistung aller durchgeführten Aktionen in Textform – siehe im Bereich Output<\/b>.<\/p>\n Wenn wir die Ergebnisse analysieren wollen, wird das je nach der Anzahl der Einträge mehr oder weniger aufwändig. Bei vielen Einträgen können wir, wie bereits weiter oben beschrieben, die Fehler, Warnungen und Informationen einzeln ein- und ausblenden. Allerdings kann es auch vorkommen, dass wir allein mehrere Hundert Einträge im Bereich Warnungen <\/b>erhalten. Da diese Einträge in dieser Ansicht nicht sortierbar sind, ist eine Idee, diese in eine Excel- oder Access-Tabelle zu kopieren und dort die entsprechenden Sortierungen und Filterungen durchzuführen.<\/p>\n Beim Markieren aller Einträge beispielsweise mit der Tastenkombination Strg + A <\/b>und dem anschließenden Einfügen in eine Tabelle stellen wir jedoch schnell fest, dass nur die aktuell sichtbaren Elemente kopiert werden. Wir können ein wenig mehr Element auf einmal kopieren, wenn wir die Anzeige dieses Bereichs vergrößern, aber bei vielen hundert Einträgen macht auch dies keinen besonderen Spaß. <\/p>\n Eine Alternative dazu ist es, den Text im Bereich Output <\/b>zu in die Zwischenablage zu kopieren und diesen in eine Excel-Tabelle einzufügen. Dieser enthält zwar nicht nur die Meldungen, sondern insgesamt alle Aktionen. <\/p>\n Damit sehen wir zwar alle Aktionen und Meldungen in einer Datei, aber richtig komfortabel ist dies noch nicht. Also gehen wir einen Schritt weiter und programmieren eine Lösung, die uns die benötigten Informationen in eine Access-Tabelle extrahiert.<\/p>\n Wichtig: Die Meldungen und den Output kann man nur innerhalb der Session einsehen. Deshalb sollten Sie diesen, wenn dieser noch genauer ausgewertet werden soll, unbedingt kopieren und an einem anderen Ort speichern, um die Meldungen später weiterverarbeiten zu können.<\/p>\n In diesem Fall können Sie direkt die Beispieldatenbank zum Auswerten der Meldungen verwenden, die wir in einem weiteren Beitrag beschreiben.<\/p>\n Die Meldungen sind nur Informationen darüber, was gegebenenfalls nicht funktioniert hat und wo man als Entwickler noch einmal hinschauen sollte. Die eigentliche Arbeit des Migration Wizard <\/b>ist jedoch die Migration der Tabellen, Indizes und Beziehungen in eine gegebenenfalls neu zu erstellende SQL Server-Datenbank, das Übertragen der Daten und, falls gewünscht, das Erstellen von Tabellenverknüpfungen in der verwendeten Datenbank mit den Tabellen im SQL Server.<\/p>\n Dieses Ergebnis schauen wir uns nun an. Der erste Teil spielt sich im SQL Server ab. Diesen sehen wir uns mit dem SQL Server Management Studio an.<\/p>\n Hier sehen wir, dass die neue Datenbank angelegt wurde und die gewünschten Tabellen enthält (siehe Bild 17).<\/p>\n Bild 17: Die neue Datenbank im SQL Server<\/span><\/b><\/p>\n Der zweite Teil ist interessanter. Hier sehen wir im Navigationsbereich von Access im oberen Bereich die lokalen Tabellen, die durch den SQL Server Migration Assistant umbenannt wurden.<\/p>\n Darunter sehen wir die neuen Tabellenverknüpfungen (siehe Bild 18).<\/p>\n Bild 18: Änderungen in der Access-Datenbank<\/span><\/b><\/p>\n Durch die Umbenennung der vorherigen Tabellen mit dem Voranstellen der Zeichenkette SSMA$<\/b> und dem Anhängen der Zeichenkette $local <\/b>und das Bezeichnen der neuen Tabellenverknüpfungen mit den Namen der ursprünglichen lokalen Tabellen kann man die Datenbank in der Regel genauso weiterverwenden wie zuvor – nur, dass die Daten jetzt aus den SQL Server-Tabellen kommen und nicht mehr aus den lokalen Access-Tabellen.<\/p>\n Aus der vorherigen lokalen Tabelle tblAnreden <\/b>ist nun die lokale Tabelle SSMA$tblAnreden$local <\/b>geworden.<\/p>\n Aber es wurden nicht nur stumpf Tabellenverknüpfungen erzeugt, wie es geschieht, wenn wir beispielsweise die Tabellen einer SQL Server-Datenbank mit dem Assistenten für das Verknüpfen mit ODBC-Datenbanken verknüpfen. <\/p>\n Wenn wir einmal die Tabellenverknüpfung tblMitarbeiter <\/b>öffnen, finden wir hier nämlich sowohl das Nachschlagefeld für das Feld AnredeID <\/b>als auch für das Feld LandID <\/b>durch ein Kombinationsfeld abgebildet vor (siehe Bild 19).<\/p>\n Bild 19: Nachschlagefelder in der verknüpften Tabelle<\/span><\/b><\/p>\n Diesen Vorteil verlieren wir spätestens dann, wenn wir die Tabellenverknüpfungen einmal löschen und erneut anlegen. Wir können dann nur Folgendes tun:<\/p>\n Der SQL Server Migration Assistant bietet eine Funktion, mit denen die Tabellenverknüpfungen rückgängig gemacht werden können. Das bedeutet, dass die Tabellenverknüpfungen gelöscht werden und die ursprünglichen lokalen Tabellen ihre alten Namen zurückbekommen.<\/p>\n Um zu erkennen, welche Tabellenverknüpfungen zu entfernen sind und welche lokalen Tabellen umbenannt werden sollen, hat der SSMA diesen Tabellen jeweils eine zusätzliche Eigenschaft hinzugefügt.<\/p>\n Mit der folgenden VBA-Prozedur können wir alle Eigenschaften einer Tabelle im Direktbereich des VBA-Editors ausgeben lassen:<\/p>\n Lassen wir diese einmal durchlaufen für eine der Tabellen, die umbenannt wurden, finden wir hier schnell die gesuchte Eigenschaft (siehe Bild 20):<\/p>\n Bild 20: Ausgabe der Tabelleneigenschaften<\/span><\/b><\/p>\n Diese heißt SSMATableState <\/b>und lautet hier back up copy<\/b>.<\/p>\n Lassen wir diese Prozedur für die per ODBC eingebundene Tabelle tblAbteilungen <\/b>laufen, finden wir eine Eigenschaft namens SSMATableState <\/b>mit dem Wert linked and backed up<\/b>.<\/p>\n Wenn wir wie in diesem Beitrag den Migration Wizard <\/b>für die Durchführung der Migration verwenden, verwendet dieser die Standardoptionen für die Migration. Wenn wir manuell ein neues Migrationsprojekt erstellen, können wir, nachdem wir die Quelldatenbank definiert haben, noch weitere Einstellungen vornehmen, bevor wir die Migration starten. <\/p>\n Diese Einstellungen können wir auch als Standard festlegen, damit auch die Migration über den Migration Wizard <\/b>mit diesen Einstellungen durchgeführt wird.<\/p>\n Dazu betätigen wir den Menüeintrag Tools|Default Project Settings <\/b>(siehe Bild 21). Unter Tools|Project Settings <\/b>können wir die Einstellungen des aktuell geöffneten Projekts individuell anpassen.<\/p>\n Bild 21: Öffnen der Standardeigenschaften<\/span><\/b><\/p>\n Auf der Seite Conversion <\/b>in dem nun erscheinenden Dialog können wir im Bereich Tables <\/b>für die Option Add timestamp columns <\/b>den Wert Always <\/b>auswählen (siehe Bild 22).<\/p>\n Bild 22: Einstellen des Anlegens von Timestamp-Feldern<\/span><\/b><\/p>\n Damit legen wir fest, dass für jede Tabelle ein Timestamp<\/b>-Feld hinterlegt wird. Access kann bei Vorhandensein von Timestamp-Feldern leichter erkennen, ob ein Datensatz seit dem Öffnen geändert wurde. Das wirkt sich nicht zuletzt auf die Performance aus, da so nicht alle Felder des Datensatzes auf Änderungen geprüft werden müssen.<\/p>\n Eine zweite Einstellung, die man in der Regel für alle Migrationen verwenden möchte, die man durchführt, sind die Zuordnungen der Datentypen der Access- und der SQL Server-Datenbank.<\/p>\n Diese finden wir im Bereich Type Mapping<\/b>. Hier können wir für jeden Access-Datentyp festlegen, in welchen Datentyp dieser im SQL Server migriert werden soll. Dies ist beispielsweise beim Datum interessant.<\/p>\n Den neueren Datentyp datetime2(0)<\/b> kann Access nicht ohne Weiteres verwenden – dazu ist beim Verknüpfen der Tabellen eine weitere Anpassung notwendig. Mehr dazu lesen Sie im Beitrag Probleme mit dem Datentyp Datum\/Uhrzeit erweitert <\/b>(www.access-im-unternehmen.de\/1501<\/b>).<\/p>\n Wir könnten in den Einstellungen also direkt festlegen, dass für neue Projekte der Datentyp date <\/b>einer Access-Datenbank in den Datentyp datetime <\/b>im SQL Server migriert wird. Dazu klicken wir doppelt auf die entsprechende Zuordnung und passen diese im Dialog Edit Type Mapping <\/b>an (siehe Bild 23).<\/p>\n Bild 23: Einstellen der Standard-Mappings<\/span><\/b><\/p>\n Sollten wir nicht allzu viele Fehlermeldungen erhalten, können wir die nun zum SQL Server migrierten und mit der Access-Datenbank verknüpften Tabellen bereits weitgehend so nutzen, wie dies zuvor mit den lokalen Tabellen der Fall war.<\/p>\n Voraussetzung dafür ist allerdings auch, dass das Datenmodell in einem Zustand ist, das eine einfache Migration zum SQL Server erlaubt. Eine wichtige Voraussetzung dabei ist, dass es für jede Tabelle, die anschließend über ODBC von Access aus bearbeitet werden können soll, ein Primärschlüsselfeld gibt. Anderenfalls können solche Tabellen nicht aktualisiert werden.<\/p>\n Hilfreich ist es auch, wenn es überall, wo es sinnvoll ist, Beziehungen zwischen den Tabellen mit referenzieller Integrität gibt.<\/p>\n Damit beugen wir allein dem Fall vor, dass es in Fremdschlüsselfeldern Karteileichen gibt, also Werte, die in den Primärschlüsselfeldern der verknüpften Tabellen nicht mehr vorhanden sind, weil diese entweder gelöscht wurden oder weil die Fremdschlüsselfelder direkt mit Werten gefüllt wurden, die in der verknüpften Tabelle gar nicht vorhanden waren.<\/p>\n Wenn die Migration der Tabellen erfolgt ist, folgt die weitere Migration. Diese besteht zuerst einmal darin, dass die Anwendung auf die Funktionalität mit den per ODBC verknüpften Tabellen getestet wird.<\/p>\n Hier dürften bereits einige Probleme auftauchen, weil zum Beispiel der Zugriff auf diese Tabellen per VBA mit den Methoden OpenRecordset <\/b>oder Execute <\/b>zu Problemen führt. Hier sind einige Umstellungen zu erledigen.<\/p>\n Wir werden in loser Folge das Thema Migration weiterhin behandeln.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.<\/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":[662024,66042024,44000022],"tags":[],"class_list":["post-55001498","post","type-post","status-publish","format-standard","hentry","category-662024","category-66042024","category-SQL_Server_und_Co"],"yoast_head":"\nErster Start des SSMA<\/h2>\n
![\"Der](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_002.png\")
<\/p>\n\n
Erstellen des Migrationsprojekts<\/h2>\n
![\"Schritt](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_003.png\")
<\/p>\nHinzufügen von Access-Datenbankdateien zum Migrationsprojekt<\/h2>\n
![\"Schritt](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_004.png\")
<\/p>\nAuswahl der Datenbankdatei bei aufgeteilten Datenbanken<\/h2>\n
\n
Auswahl der zu migrierenden Objekte<\/h2>\n
![\"Schritt](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_005.png\")
<\/p>\nVerbinden zum SQL Server oder zur Azure Datenbank<\/h2>\n
![\"Schritt](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_006.png\")
<\/p>\n\n
![\"Einstellungen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_007.png\")
<\/p>\n![\"Frage,](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_008.png\")
<\/p>\nOptional: Verknüpfen der migrierten Tabellen<\/h2>\n
![\"Schritt](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_009.png\")
<\/p>\nÜbertragen der Objekte und Migrieren der Daten<\/h2>\n
![\"Migration:](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_010.png\")
<\/p>\n![\"Zuordnung](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_011.png\")
<\/p>\n![\"Anlegen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_012.png\")
<\/p>\n![\"Migrieren](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_013.png\")
<\/p>\n![\"Abschluss](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_014.png\")
<\/p>\nFehler, Warnungen und Hinweise untersuchen<\/h2>\n
![\"Untersuchen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_015.png\")
<\/p>\nErgebnis im SQL Server Migration Assistant betrachten<\/h2>\n
![\"Der](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_016.png\")
<\/p>\nAnalysieren der Ergebnisse<\/h2>\n
Weitere Ergebnisse der Migration<\/h2>\n
![\"Die](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_017.png\")
<\/p>\n![\"Änderungen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_018.png\")
<\/p>\nNachschlagefelder bleiben erhalten<\/h2>\n
![\"Nachschlagefelder](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_019.png\")
<\/p>\n\n
Weitere Besonderheiten der umbenannten lokalen Tabellen und der Tabellenverknüpfungen<\/h2>\n
Public Sub <\/span>Tabelleneigenschaften(strTabelle As String<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>tdf As <\/span>DAO.TableDef\r\n Dim <\/span>prp As <\/span>DAO.Property\r\n Dim <\/span>strValue As String<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> tdf = db.TableDefs(strTabelle)\r\n For Each prp In tdf.Properties\r\n strValue = \"\"\r\n On Error Resume Next<\/span>\r\n strValue = prp.Value\r\n If <\/span>Err.Number = 0 Then<\/span>\r\n Debug.Print<\/span> prp.Name, prp.Value\r\n Else<\/span>\r\n Debug.Print<\/span> prp.Name, Err.Number, Err.Description\r\n End If<\/span>\r\n On Error GoTo<\/span> 0\r\n Next<\/span> prp\r\nEnd Sub<\/span><\/pre>\n![\"Ausgabe](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_020.png\")
<\/p>\nTabelleneigenschaften \"SSMA$tblAbteilungen$local\"<\/pre>\n
Voreinstellungen von Optionen für die Migration<\/h2>\n
![\"Öffnen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_021.png\")
<\/p>\nImmer Timestamp-Feld hinzufügen<\/h2>\n
![\"Einstellen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_022.png\")
<\/p>\nDatentyp-Mapping<\/h2>\n
![\"Einstellen](\"..\/fileadmin\/_temp_\/2024_04\/pic_1498_023.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n