Sql server 附加DB"；继承；从以前附加了相同名称的数据库更改架构

我们刚刚遇到一个问题，一个新连接的Dev实例“拾取”了对以前的Dev数据库所做的模式更改，但在将其重命名并连接为Dev之前，该更改不存在于Live DB副本中

Dev DB作为日志传送备用启动，完全恢复、分离、重命名文件，然后作为新的Dev DB重新连接。请注意，以前的Dev数据库并没有被删除，只是被分离。还要注意，旧的和新的Dev数据库都是同一原始数据库的“分叉”

现在这是一个开发/测试环境，所以它不是特别有问题，但它让我担心我们会创建一些东西来对抗一个静默更改的开发环境，当它被应用时，它将中断运行

因此，我的工作原理是，这与SQLServer内部使用的唯一标识符有关，也可能与对开发人员进行更改的时间有关

有人能证实这一点，或者对这个问题有什么解释吗

编辑：进一步详细信息 模式更改涉及在一些表的末尾添加新的可空列。因此，它们被承认是次要的，重要的是不涉及任何实际数据。此外，日志传送副本一直处于备用状态，直到它被重新附加（因此是只读的），我已经查看了查询日志，以验证没有运行DDL更改

尽管如此，不幸的是，我无法复制这个问题。创建一个小数据库只是为了测试它，而不是为了测试它。为了解决这个问题，我删除了Dev DB，并从完整备份中重新创建了它，所以我不能重复确切的过程

---

我问这个问题的目的是确定我们是否经历了一次意外的侥幸，或者我们的过程根本不健全。目前，我倾向于非常侥幸。

SQL Server不具备神奇的性能。如果你附加了一个数据库，并且模式更改在那里，那么更改在附加它之前就在文件中了。你的工作原理不可能是正确的，我的好人。我不确定您的流程哪里出了问题，但SQL server不能像这样更改模式。我不知道这件事还能告诉你什么。仔细检查您的流程。感谢您富有洞察力的评论。：/SQL Server将数据库之外的架构信息存储在“msdb”系统数据库中，以及数据库标识数据、备份历史记录等。因此，在确认确实发生了这种情况后，问题是是否有其他人经历过这种情况。您没有提供太多详细信息。你到底指的是什么“模式变化”，你是如何观察它们的？如果使用备份/恢复而不是附加/分离，会发生什么情况？由于所讨论的数据库是一个日志传送目标，您确定数据库在分离时的状态是“稳定”的吗？什么版本的SQL Server？能否显示用于分离/重命名/附加的脚本？仅仅附加一个数据库是无法改变模式的，所以脚本中很可能有错误，但我们不知道您在做什么。@Pondlife补充了更多细节，我编写了脚本来尝试并复制它，但事实上它在测试中工作得很好。我想我们会看看这个问题是否能让其他有过类似经历的人大吃一惊。