Pièges à éviter lors de l'utilisation de la nouvelle version 7.8 de Microsoft SSMA
Microsoft met régulièrement à jour ses assistants de gestion SQL Server et vient de mettre à jour le SSMA pour Access. Cependant, vous ne pouvez pas voir les nouveautés de la version 7.8 dans leur documentation officielle. La dernière version de SQL Server Migration Assistant (SSMA) version 7.8 peut être téléchargée ici.
La version 7.8 est beaucoup plus facile que la précédente, en particulier avec la gestion du 32/64 bits, mais il y a des bizarreries que nous allons examiner.
Quelle version dois-je télécharger ?
SSMA doit pouvoir se connecter à Access et pour ce faire, il doit avoir le même nombre de bits que l'Access installé. Pour cette raison, si vous disposez d'un accès 32 bits, vous devez télécharger et installer le SSMA 32 bits. Notez que les programmes 32 bits sont également appelés "x86". Sinon, vous devez installer SSMA 64 bits pour fonctionner avec un accès 64 bits.
Commentaires positifs
J'ai adoré le fait que SSMA ait reconnu dès le début que le serveur était sur Azure SQL. Gros plus, bravo !
Lorsque vous utilisez Office365, vous devez télécharger Access Database Engine 2010
Il n'y a pas longtemps, j'avais besoin de l'installer sur la machine virtuelle d'un client et, en le faisant, je suis tombé sur ces erreurs/bogues.
Lors de l'exécution d'Office 365, vous devrez télécharger le moteur de base de données Microsoft Access 2010 redistribuable afin que SSMA puisse lire vos données Access. Microsoft Access fourni avec Office365 se trouve dans un environnement sandbox et n'est donc pas accessible à SSMA.
Problèmes supplémentaires que vous pouvez rencontrer avec SSMA
Après avoir installé Microsoft Access Database Engine 2010 Redistributable, j'ai rencontré une autre erreur, également liée à Office 365. Ce fil de discussion peut vous aider !
Afin de résoudre le problème, j'ai désinstallé Office 16 Click-To-Run Extensibility Component 64-bit Registration – voir image ci-dessous.
Je n'ai pas pu migrer toutes les tables en même temps
Après m'être connecté à SQL Server, j'ai sélectionné les tables que je voulais synchroniser et j'ai appuyé sur le 
bouton. La migration n'a pas eu lieu pour toutes les tables, mais une seule ! Je n'ai donc pu migrer qu'une seule table à la fois, ce qui est terrible. Pensez à devoir migrer plus de 100 tables et requêtes, ce n'était pas mon problème, mais c'est quand même... un cauchemar.
Vous devrez ajouter vous-même les clés étrangères
Ma base de données Access locale n'avait aucune contrainte de clé étrangère configurée. Lors de la migration vers SQL, SSMA ne m'a pas demandé de définir des contraintes de clé étrangère. Techniquement, ce n'est pas un problème avec l'outil SSMA lui-même, mais quelque chose à savoir et à vérifier lors de la migration puisque, je suppose, la base de données d'origine n'avait aucune contrainte, nous devons donc nous assurer de l'appliquer. SSMA devrait le faire pour nous.
Quels bogues ou erreurs avez-vous rencontrés lors de l'utilisation de SSMA ? Où ils sont cruciaux pour votre projet ? Faites-le nous savoir dans les commentaires ci-dessous.
