Zu vermeidende Fallstricke bei der Verwendung der neuen Microsoft SSMA-Version 7.8

Microsoft hat seine SQL Server-Verwaltungsassistenten regelmäßig aktualisiert, und sie haben gerade den SSMA für Access aktualisiert. In der offiziellen Dokumentation können Sie jedoch nicht sehen, was für 7.8 neu ist. Die neueste Version 7.8 des SQL Server-Migrationsassistenten (SSMA) kann hier heruntergeladen werden.

Die 7.8-Version ist viel einfacher als die vorherige, insbesondere im Umgang mit 32/64-Bits, aber es gibt Macken, die wir uns ansehen werden.

Welche Version soll ich herunterladen?

SSMA muss in der Lage sein, eine Verbindung mit Access herzustellen, und dazu muss es die gleiche Anzahl von Bits wie der installierte Access haben. Aus diesem Grund sollten Sie, wenn Sie über 32-Bit-Zugriff verfügen, das 32-Bit-SSMA herunterladen und installieren. Beachten Sie, dass 32-Bit-Programme auch als „x86“ bezeichnet werden. Andernfalls sollten Sie 64-Bit-SSMA installieren, um mit 64-Bit-Zugriff zu arbeiten.

Positives Feedback

Mir gefiel die Tatsache, dass SSMA von Anfang an erkannte, dass der Server auf Azure SQL lief. Großes Plus, Daumen hoch!

Wenn Sie Office365 verwenden, müssen Sie Access Database Engine 2010 herunterladen

Vor nicht allzu langer Zeit musste ich es auf der VM eines Kunden installieren und bin dabei auf diese Fehler / Bugs gestoßen.

Wenn Sie Office 365 ausführen, müssen Sie die Microsoft Access Database Engine 2010 Redistributable herunterladen, damit SSMA Ihre Access-Daten lesen kann. Das mit Office365 gelieferte Microsoft Access befindet sich in einer Sandbox-Umgebung und ist daher für SSMA nicht zugänglich.

Zusätzliche Probleme, die bei SSMA auftreten können

Nach der Installation von Microsoft Access Database Engine 2010 Redistributable trat ein weiterer Fehler auf, der ebenfalls mit Office 365 zusammenhängt. Dieser Thread kann hilfreich sein!

Um das Problem zu beheben, habe ich die Office 16 Click-to-Run Extensibility Component 64-bit Registration deinstalliert – siehe Bild unten.

Ich konnte nicht alle Tabellen gleichzeitig migrieren

Nachdem ich mich bei SQL Server angemeldet hatte, wählte ich die Tabellen aus, die ich synchronisieren wollte, und traf die  Schaltfläche. Die Migration erfolgte aber nicht für alle Tische, sondern nur für einen! Ich konnte also nur jeweils eine Tabelle migrieren, was schrecklich ist. Denken Sie daran, mehr als 100 Tabellen und Abfragen migrieren zu müssen, das war nicht mein Problem, aber trotzdem … ein Albtraum.

Sie müssen Fremdschlüssel selbst hinzufügen

In meiner lokalen Access-Datenbank waren keine Fremdschlüsseleinschränkungen eingerichtet. Bei der Migration zu SQL hat mich SSMA nicht aufgefordert, Fremdschlüsseleinschränkungen festzulegen. Technisch gesehen kein Problem mit dem SSMA-Tool selbst, aber etwas, das Sie bei der Migration beachten und überprüfen sollten, da die ursprüngliche Datenbank meiner Meinung nach keine Einschränkungen hatte, also müssen wir sicherstellen, dass wir sie durchsetzen. SSMA sollte das für uns erledigen.

Welche Bugs oder Fehler sind bei der Verwendung von SSMA aufgetreten? Waren sie entscheidend für Ihr Projekt? Lass es uns unten in den Kommentaren wissen.