新しいMicrosoftSSMAバージョン7.8を使用する際に避けるべき落とし穴

MicrosoftはSQLServerManagement Assistantを定期的に更新しており、AccessのSSMAを更新したばかりです。ただし、公式ドキュメントでは7.8の新機能を確認できません。 SQL Server Migration Assistant（SSMA）バージョン7.8の最新バージョンは、こちらからダウンロードできます。

7.8バージョンは、特に32/64ビットを処理する場合、以前よりもはるかに簡単ですが、これから検討する癖があります。

どのバージョンをダウンロードする必要がありますか？

SSMAはAccessに接続できる必要があり、そのためには、インストールされているAccessと同じビット数である必要があります。そのため、32ビットアクセスを使用している場合は、32ビットSSMAをダウンロードしてインストールする必要があります。 32ビットプログラムは「x86」とも呼ばれることに注意してください。それ以外の場合は、64ビットアクセスで動作するように64ビットSSMAをインストールする必要があります。

正のフィードバック

SSMAが、サーバーがAzureSQL上にあることを最初から認識していたという事実が気に入りました。大きなプラス、いいね！

Office365を使用する場合は、Access DatabaseEngine2010をダ​​ウンロードする必要があります

少し前に、クライアントのVMにインストールする必要がありましたが、その間に、これらのエラーやバグに遭遇しました。

Office 365を実行している場合、SSMAがAccessデータを読み取れるように、Microsoft Access DatabaseEngine2010再頒布可能パッケージをダウンロードする必要があります。 Office365に付属のMicrosoftAccessはサンドボックス環境にあるため、SSMAにアクセスできません。

SSMAで発生する可能性のあるその他の問題

Microsoft Access Database Engine 2010再頒布可能パッケージをインストールした後、Office 365に関連する別のエラーが発生しました。このスレッドが役立つ場合があります！

この問題を解決するために、 Office 16 Click-To-Run ExtensibilityComponent64ビット登録をアンインストールしました。 –下の画像を参照してください。

すべてのテーブルを同時に移行できませんでした

SQL Serverにログインした後、同期したいテーブルを選択して、 ボタン。ただし、移行はすべてのテーブルで行われたわけではなく、1つだけでした。そのため、一度に1つのテーブルしか移行できませんでしたが、これはひどいことです。 100以上のテーブルとクエリを移行する必要があることを考えてみてください。それは私の問題ではありませんでしたが、それでも…悪夢です。

自分で外部キーを追加する必要があります

私のローカルAccessデータベースには、外部キー制約が設定されていませんでした。 SQLに移行するとき、SSMAは外部キー制約を設定するように要求しませんでした。技術的にはSSMAツール自体の問題ではありませんが、元のデータベースには制約がなかったため、移行時に注意して確認する必要があります。そのため、必ず適用する必要があります。 SSMAは私たちのためにそれを行う必要があります。

SSMAを使用すると、どのようなバグやエラーが発生しましたか？それらがあなたのプロジェクトにとって重要なのはどこですか？以下のコメントでお知らせください。