{"id":55000484,"date":"2025-10-01T00:00:00","date_gmt":"2025-12-28T17:35:26","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=484"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"AccessDatenbank_zum_SQL_Server_migrieren","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/AccessDatenbank_zum_SQL_Server_migrieren\/","title":{"rendered":"Access-Datenbank zum SQL Server migrieren"},"content":{"rendered":"

\"\"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.<\/b><\/p>\n

SQL Server Migration Assistant herunterladen und installieren<\/h2>\n

Die jeweils aktuelle Version des SQL Server Migration Assistant finden wir, wenn wir im Internet nach genau diesen Schlüsselwörtern suchen.<\/p>\n

Wir landen dann beispielsweise auf einer Seite wie der aus Bild 1. Hier klicken wir nicht etwa auf SQL Server Migration Assistant for Access<\/b>, sondern scrollen weiter nach unten, wo wir unter Downloads <\/b>den Eintrag SSMA for Access <\/b>finden.<\/p>\n

\"Download<\/p>\n

Bild 1: Download des SQL Server Migration Assistant<\/span><\/b><\/p>\n

Auf der nun erscheinenden Seite klicken wir auf Download<\/b>. Die Sprache können wir nicht ändern, da der SSMA nur in Englisch verfügbar ist.<\/p>\n

Richtige Bitness auswählen<\/h2>\n

Es erscheint ein Popup, das die verschiedenen Versionen auflistet (siehe Bild 2). Hier gibt es zum Beispiel zwei verfügbare Versionen (9.5 <\/b>und 10.4<\/b>), die jeweils für 32-Bit und 64-Bit verfügbar sind.<\/p>\n

\"Auswahl<\/p>\n

Bild 2: Auswahl der richtigen Version<\/span><\/b><\/p>\n

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<\/b>) 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.<\/p>\n

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<\/b> und im nun erscheinenden Bereich links auf Konto<\/b>.<\/p>\n

Rechts sehen wir nun eine Schaltfläche namens Info zu Access<\/b>. Damit öffnen wir den Dialog aus Bild 3. Oben sehen wir nun entweder den Text 32 Bit <\/b>oder 64 Bit<\/b>. 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<\/b>.<\/p>\n

\"Ermitteln<\/p>\n

Bild 3: Ermitteln der Bitness der Access-Installation<\/span><\/b><\/p>\n

Migration vorbereiten<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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:<\/p>\n

    \n
  • Die vorhandenen lokalen Tabellen werden nach einem bestimmten Schema umbenannt.<\/li>\n
  • Es werden Tabellenverknüpfungen zu den migrierten Tabellen angelegt.<\/li>\n<\/ul>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Migrieren der Access-Datenbank<\/h2>\n

    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.<\/p>\n

    Wenn wir den SQL Server Migration Assistant gestartet haben, zeigt dieser standardmäßig gleich den Migration Wizard<\/b> 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<\/b> manuell aufrufen.<\/p>\n

    \"Start<\/p>\n

    Bild 4: Start des SQL Server Migration Assistants<\/span><\/b><\/p>\n

    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).<\/p>\n

    \"Angabe<\/p>\n

    Bild 5: Angabe eines Projektnamens<\/span><\/b><\/p>\n

    Außerdem legen wir hier fest, zu welcher SQL Server-Version wir die Access-Datenbank migrieren wollen – hier SQL Server 2022<\/b>.<\/p>\n

    SQL Server-Version ermitteln<\/h2>\n

    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 <\/b>aus.<\/p>\n

    Hier gibst Du den folgenden Befehl ein und führst diesen mit der Taste F5 <\/b>aus:<\/p>\n

    SELECT @@Version<\/pre>\n
    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.<\/p>\n
    \"Ermitteln<\/p>\n
    Bild 6: Ermitteln der SQL Server-Version<\/span><\/b><\/p>\n
    Im SSMA klicken wir nun auf Next <\/b>und landen im nächsten Schritt, in dem wir über die Schaltfläche Add Databases <\/b>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.<\/p>\n
    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.<\/p>\n
    Lokale und verknüpfte Access-Tabellen<\/h2>\n
    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.<\/p>\n
    Hier hat man zwei Möglichkeiten:<\/p>\n
      \n
    • Man gibt die Frontend-Datenbank als Quelle für die Migration an, wodurch man sowohl lokale Tabellen als auch verknüpfte Tabellen migrieren kann.<\/li>\n
    • 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.<\/li>\n<\/ul>\n
      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.<\/p>\n
      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.<\/p>\n
      Wir würden also an dieser Stelle normalerweise die Frontenddatenbank mit dem Tabellenverknüpfungen zur Backenddatenbank auswählen.<\/p>\n
      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.<\/p>\n
      Tabellen für die Migration auswählen<\/h2>\n
      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<\/b> 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.<\/p>\n
      \"Auswählen<\/p>\n
      Bild 7: Auswählen der zu migrierenden Tabellen<\/span><\/b><\/p>\n
      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.<\/p>\n
      SQL Server und Zieldatenbank festlegen<\/h2>\n
      Im vorliegenden Fall können wir jedoch alle Tabellen migrieren, daher klicken wir auf Next<\/b> 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.<\/p>\n
      \"Festlegen<\/p>\n
      Bild 8: Festlegen des Ziel-SQL Servers<\/span><\/b><\/p>\n
      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 <\/b>auswählst, musst Du noch den Benutzernamen und das Kennwort für den Benutzer angeben, unter dem Du Zugriff auf den SQL Server hast.<\/p>\n
      Außerdem gibst Du noch an, ob die Verbindung verschlüsselt erfolgen soll (Encrypt Connection<\/b>) und ob Du dem Server-Zertifikat vertrauen möchtest (Trust Server Certificate<\/b>). 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.<\/p>\n
      Klicken wir nun auf Next<\/b>, 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.<\/p>\n
      \"Soll<\/p>\n
      Bild 9: Soll die Datenbank erstellt werden?<\/span><\/b><\/p>\n
      Tabellenverknüpfungen erstellen<\/h2>\n
      Im nächsten Schritt folgt die Frage, ob in Access nach der Migration direkt Tabellenverknüpfungen zu den Tabellen in der neuen SQL Server-Datenbank angelegt werden sollen. Das bestätigen wir, indem wir die Option Link Tables <\/b>aktivieren (siehe Bild 10).<\/p>\n
      \"Sollen<\/p>\n
      Bild 10: Sollen Tabellenverknüpfungen erstellt werden?<\/span><\/b><\/p>\n
      Durchführen der Migration<\/h2>\n
      Im nächsten Schritt beginnt bereits die Migration. Der SSMA zeigt nun den Fortschritt der Migration an und wir erhalten live die Anzahl der Fehler, Warnungen und Hinweise in den verschiedenen Schritten der Migration (siehe Bild 11).<\/p>\n
      \"Der<\/p>\n
      Bild 11: Der SSMA arbeitet.<\/span><\/b><\/p>\n
      Synchronisieren der Tabellen<\/h2>\n
      Der SQL Server Migration Assistant kann nur Annahmen treffen, wie die Tabellen migriert werden sollen. Deshalb zeigt er im nächsten Schritt den Dialog aus Bild 12 an.<\/p>\n
      \"Das<\/p>\n
      Bild 12: Das Zuordnen der Tabellen ist bei der initialen Migration nicht erforderlich.<\/span><\/b><\/p>\n
      Klappen wir das Element Tables<\/b> auf, sehen wir auf der rechten Seite alle Tabellen der Access-Datenbank und auf der linken Seite jeweils die Zuordnung zu einem Eintrag namens [Not found]<\/b>.<\/p>\n
      Das liegt daran, dass die Zieldatenbank noch keine Tabellen enthält.<\/p>\n
      Wenn wir später eine weitere Migration auf die gleiche Zieldatenbank durchführen, erhalten wir an dieser Stelle ein Mapping der Access-Tabellen auf die gleichnamigen Tabellen im SQL Server. Diese würden dann beim Beibehalten der Zuordnung durch die neuen Tabellen überschrieben werden.<\/p>\n
      Bei der ersten Migration einer Datenbank können wir hier einfach auf OK <\/b>klicken.<\/p>\n
      Verbindungsdaten für die Tabellenverknüpfungen angeben<\/h2>\n
      Der SSMA setzt nun die Migration fort. Wenn wir weitere oben angegeben haben, dass wir direkt Tabellenverknüpfungen in der Access-Datenbank erstellen wollen, erscheint nun die Meldung aus Bild 13.<\/p>\n
      \"Auswahl<\/p>\n
      Bild 13: Auswahl der Authentifizierungsmethode zum Anlegen der Tabellenverknüpfungen<\/span><\/b><\/p>\n
      Hier geben wir an, unter welcher Anmeldung die Tabellenverknüpfungen erstellt werden sollen. Meistens wählt man hier Windows Integrated <\/b>aus, was der Windows-Authentifizierung entspricht. Wenn die Migration im Kontext eines SQL Server-Benutzers durchgeführt und die Tabellenverknüpfungen im gleichen Kontext angelegt werden sollen, können wir hier auch den Wert SQL Server <\/b>beibehalten. Dann müssen wir aber noch den Benutzernamen und das Kennwort angeben.<\/p>\n
      Abschluss der Migration<\/h2>\n
      Nachdem der SSMA auch noch die Tabellenverknüpfungen angelegt hat, sehen wir den abschließenden Status der Migration wie in Bild 14.<\/p>\n
      \"Ergebnis<\/p>\n
      Bild 14: Ergebnis der Migration<\/span><\/b><\/p>\n
      Hier können wir mit einem Klick auf die Links die Fehler, Warnungen und Informationen einsehen. Wie bereits erwähnt, wollen wir in diesem Artikel nicht auf die möglichen Fehler eingehen, da dies den Rahmen sprengen würde. Also schließen wir den Bericht mit einem Klick auf Close<\/b>.<\/p>\n
      Danach sehen wir nur noch das Hauptfenster des SQL Server Migration Assistants, wo wir für das aktuelle Projekt noch einmal die Fehler, Warnungen und Informationen einsehen können (siehe Bild 15).<\/p>\n
      \"Überblick<\/p>\n
      Bild 15: Überblick über Fehler, Warnungen und Informationen<\/span><\/b><\/p>\n
      Danach können wir den SSMA schließen und gegebenenfalls noch das Speichern des soeben angelegten Projekts bestätigen.<\/p>\n
      Ergebnis in der Access-Datenbank <\/h2>\n
      Uns interessiert an dieser Stelle viel mehr, was nun in der migrierten Access-Datenbank geschehen ist. Dazu öffnen wir diese und sehen im Navigationsbereich nun zwei Änderungen (siehe Bild 16):<\/p>\n
      \"Die<\/p>\n
      Bild 16: Die umbenannten Tabellen und die neuen Tabellenverknüpfungen im Navigationsbereich<\/span><\/b><\/p>\n
        \n
      • Die durch das entsprechende Icon als lokal markierten Tabellen wurden umbenannt. Dabei wurde vorn der Text SSMA$ <\/b>und hinten $local <\/b>angefügt.<\/li>\n
      • Außerdem finden wir hier neue, per ODBC verknüpfte Tabellen vor.<\/li>\n<\/ul>\n
        Öffnen wir eine der verknüpften Tabellen, werden die Daten genauso angezeigt, wie sie auch bei einer lokalen Tabelle erscheinen würden. Das Migrieren und anschließende Verknüpfen sorgt also dafür, dass wir erst einmal wie gewohnt mit den Daten weiterarbeiten können – nur dass diese sich nun nicht mehr in der Access-Datenbank befinden, sondern in der SQL Server-Datenbank.<\/p>\n
        Geänderte Eigenschaften der lokalen Tabellen<\/h2>\n
        Wir wollen uns noch den Grund ansehen, warum wir nach dem Löschen der Tabellenverknüpfungen und dem Umbenennen der lokalen Tabellen mit den ursprünglichen Namen nicht einfach eine neue Migration starten können.<\/p>\n
        Dazu verwenden wir eine VBA-Prozedur namens Tabelleneigenschaften<\/b>, die alle nicht standardmäßigen Eigenschaften einer Access-Tabelle ausgibt. Die Prozedur sehen wir in Listing 1.<\/p>\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>tdfDefault As <\/span>DAO.TableDef\r\n     Dim <\/span>prp As <\/span>DAO.Property\r\n     Dim <\/span>prpDefault As <\/span>DAO.Property\r\n     Dim <\/span>strValue As String<\/span>\r\n     Dim <\/span>bolDefault As Boolean<\/span>\r\n     \r\n     Set<\/span> db = CurrentDb\r\n     Set<\/span> tdf = db.TableDefs(strTabelle)\r\n     Set<\/span> tdfDefault = db.TableDefs(\"tblDefault\")\r\n     \r\n     For Each prp In tdf.Properties\r\n         bolDefault = False<\/span>\r\n         For Each prpDefault In tdfDefault.Properties\r\n             If <\/span>prpDefault.Name = prp.Name Then<\/span>\r\n                 bolDefault = True<\/span>\r\n                 Exit For<\/span>\r\n             End If<\/span>\r\n         Next<\/span> prpDefault\r\n         If <\/span>bolDefault = False<\/span> Then<\/span>\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         End If<\/span>\r\n     Next<\/span> prp\r\nEnd Sub<\/span><\/pre>\n
        Listing 1: Funktion zum Ausgeben nicht standardmäßiger Tabelleneigenschaften<\/span><\/b><\/p>\n
        Wie bekommen wir alle nicht standardmäßigen Eigenschaften heraus? In dem wir eine frische Tabelle mit wenigen Beispielfeldern anlegen und dann untersuchen, welche Eigenschaften die zu untersuchende Tabelle im Gegensatz zu der Standardtabelle hat.<\/p>\n
        Wir haben dazu eine neue Tabelle namens tblDefault <\/b>hinzugefügt, die nur zwei Felder enthält und an der wir sonst keinerlei Eigenschaften angepasst haben.<\/p>\n
        Die Prozedur Tabelleneigenschaften <\/b>erwartet den Namen der zu untersuchenden Tabelle als Parameter. Sie erstellt zwei TableDef<\/b>-Objekte namens tdf <\/b>und tdfDefault <\/b>und füllt diese mit der zu untersuchenden Tabelle und der Tabelle tblDefault<\/b>.<\/p>\n
        Dann durchläuft sie in einer For Each<\/b>-Schleife alle Einträge der Properties <\/b>-Auflistung der Tabelle aus tdf<\/b>. In einer weiteren For Each<\/b>-Schleife durchläuft sie alle Properties der Tabelle aus tdfDefault <\/b>und prüft, ob der Name der aktuellen Eigenschaft aus tdf<\/b>, die wir mit prp <\/b>referenziert haben, mit dem Namen der aktuellen Eigenschaft aus prpDefault <\/b>übereinstimmt.<\/p>\n
        Ist dies der Fall, handelt es sich gemäß unserer Definition um eine nicht standardmäßige Eigenschaft und wir stellen die Variable bolDefault <\/b>auf True <\/b>ein und verlassen die innere For Each<\/b>-Schleife.<\/p>\n
        Dann prüfen wir per If…Then<\/b>-Bedingung, ob bolDefault <\/b>den Wert False <\/b>enthält und geben nur dann den Namen und den Wert der nicht standardmäßigen Eigenschaft im Direktbereich aus.<\/p>\n
        Die Prozedur rufen wir beispielsweise wie folgt auf, wenn wir die Tabellenverknüpfung tblMitarbeiter <\/b>untersuchen wollen:<\/p>\n
        Call<\/span> Tabelleneigenschaften(\"tblMitarbeiter\")<\/pre>\n
        Das Ergebnis im Direktbereich sieht wie folgt aus:<\/p>\n
        SSMATableState              linked and backed up<\/pre>\n
        Der SQL Server Migration Assistant hat also eine neue Eigenschaft namens SSMATableState <\/b>hinzugefügt, die den Wert linked and backed up <\/b>enthält, was bedeutet: Die Originaltabelle wurde kopiert und die neu erstellte Tabelle verknüpft.<\/p>\n
        Für die nach SSMA$tblMitarbeiter$local <\/b>kopierte Tabelle erhalten wir unter anderem die folgende neue Eigenschaft:<\/p>\n
        SSMATableState              back up copy<\/pre>\n
        Dies deutet also darauf hin, dass es sich hier um die kopierte Tabelle handelt.<\/p>\n
        Wenn wir also dafür sorgen wollen, dass wir die Tabellen dieser Datenbank erneut migrieren können, müssen wir die Eigenschaft SSMATableState <\/b>aus den entsprechenden Tabellen entfernen, die Tabellenverknüpfungen löschen und die gesicherten Tabellen wieder umbenennen, beispielsweise von SSMA$tblMitarbeiter$local <\/b>nach tblMitarbeiter<\/b>.<\/p>\n
        Zum Glück müssen wir das nicht von Hand erledigen, sondern der SQL Server Migration Assistant bietet eine entsprechende Funktion an.<\/p>\n
        Dazu starten wir diesen erneut und öffnen das zuletzt gespeicherte Migrationsprojekt. Hier klicken wir mit der rechten Maustaste im Bereich Access Metadata Explorer <\/b>auf das Element für die Datenbank und wählen den Befehl UnlinkTables<\/b> aus (siehe Bild 17).<\/p>\n
        \"Rückgängig<\/p>\n
        Bild 17: Rückgängig machen von Verknüpfungen und Backups<\/span><\/b><\/p>\n
        Die Datenbank muss geschlossen sein, damit der SSMA auf die Tabellen zugreifen kann. Danach finden wir wieder die Originaltabellen vor und können die Datenbank erneut migrieren.<\/p>\n
        Zusammenfassung und Ausblick<\/h2>\n
        Dieser Artikel beschreibt, wie man mit dem SQL Server Migration Assistant eine initiale Migration zum SQL Server durchführt und als Ergebnis eine Datenbank erhält, die bereits Tabellenverknüpfungen auf die im SQL Server angelegten Tabellen bereitstellt.<\/p>\n
        Weitere Schritte sind die Untersuchung der beim Migrieren auftauchenden Fehlermeldungen und deren Behebung sowie das erneute Ausführen der Migration, bis sich schließlich eine Migration ohne Fehlermeldung ausführen lässt.<\/p>\n","protected":false},"excerpt":{"rendered":"
        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.<\/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":[662025,66052025,44000026,44000006,44000031],"tags":[],"yst_prominent_words":[],"class_list":["post-55000484","post","type-post","status-publish","format-standard","hentry","category-662025","category-66052025","category-Outlook_programmieren","category-SQL_Server_und_Co","category-twinBASICProgrammierung"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000484","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/comments?post=55000484"}],"version-history":[{"count":0,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000484\/revisions"}],"wp:attachment":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/media?parent=55000484"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/categories?post=55000484"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/tags?post=55000484"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/yst_prominent_words?post=55000484"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}