我正在尝试使用 SSDT 架构比较来更新 Visual Studio 2019 中的 SQL Server 项目。我的源是正在运行的数据库服务器，目标是 VS SQL Server 项目。
比较完成并单击“更新”后，我收到消息
检测到源架构漂移。按比较刷新比较
无论我刷新比较多少次，总是得到相同的结果。
我尝试了各种连接调整（只读意图、异步处理、多个活动结果集），希望能够使比较运行得更快并在漂移发生之前更新项目，但无济于事。我还尝试减少比较中包含的对象类型，但无法减少到足以防止检测到漂移。
我认为我遇到的最大问题是，除了“检测到架构漂移”消息之外，我觉得我是在黑暗中拍摄。我的意思是我不知道什么导致 SSDT 检测到漂移，因此我无法解决它。
我尝试运行 SQL Profiler 来捕获 SSDT 正在执行的操作，以便我可以找到 SSDT 检测漂移的位置。但是，我还没有找到任何在短时间内运行多次时给出不同结果的查询。
总而言之，我的问题是：
我也花了几个月的时间寻找同样错误的原因。我已经在考虑在我的笔记本电脑上刷新 Windows 10。我不会再列出死胡同了。在我最后的绝望中，我将 SQL Server 数据库和 VS 项目复制到另一台机器上，在那里进行了没有骨头的比较。我怀疑错误可能不在VS中，而是我的SQL服务器混淆了VS。 我有一个 SQL Server 2012。我在上面安装了最新的更新 (SP4)，奇迹中的奇迹、比较和同步立即开始完美运行。当然，现在在每次更新之前我都会祈祷一点，这样我就不会遇到“检测到源架构漂移”消息。
对于许多 SSDT 版本，我一直未能成功地解决这个恼人的错误。
搜索它，您会看到多个地方声称已修复，这是错误的，因为 VS 2022 SSDT 现在正在发生这种情况。
就我而言，只有在与我经常使用该工具的 5 个数据库服务器之一进行比较时才会发生这种情况。
我发现通常有效的唯一解决方法是重新启动目标数据库服务器（不仅仅是循环 SQL Server 服务），然后快速运行 SSDT 比较！
由于发生这种情况的服务器是在我的本地网络中的虚拟机上运行的集成服务器，因此我可以退回该服务器，但在其他情况下，这将是一个阻碍。
IMO 关于这个问题最繁重的事情是你甚至无法生成复制/粘贴到 SSMS 的脚本，这就是我经常使用该工具的方式。
这个问题多年来一直没有得到解决，而且非常间歇性，所以我不希望看到它真正得到解决 - 我希望这个解决方法对某人有帮助。
我见过的唯一有希望的解决方法与项目本身的文件夹结构有关。该错误与实际数据库的状态无关。这并不是因为有太多开发人员在开发数据库上工作，并且架构实际上已经发生了变化。您需要进行项目设置，以便解决方案文件和 sqlproj 文件位于同一目录中，这是数据库项目的非默认设置。如果您希望在同一个解决方案（或存储库）中使用多个数据库项目，那么您就不走运了。是时候将它们分成单独的存储库了，因此每个解决方案文件只有一个 sqlproj 文件。