2

我在我的 T-SQL 代码库中使用 DBDeploy.NET 进行变更控制管理。DBDeploy 由开发人员维护一组编号的更改脚本。当（通过 NAnt）触发部署时，DBDeploy 会查看更改日志表并确定需要执行哪些补丁以使实例保持最新状态。

我遇到的问题是设置创建索引视图所需的设置。QUOTED_IDENTIFIER、ANSI_NULLS 和 ARITHABORT 都需要打开。是的，我可以轻松地将这些 SET 语句放在创建/更改索引视图的更改脚本的顶部。但这些设置是连接级别的。如果以后我要从头开始构建一个新实例怎么办？当我在新实例上运行 DBDeploy 时，这些设置将传递到所有后续更改脚本，因为所有更改脚本都有效地连接到最终 SQL 脚本中，以便在单个连接上执行。更糟糕的是解析时选项，如 QUOTED_IDENTIFIER，它也将应用于之前的所有更改脚本。所以：

  1. 我使用的是 SQL Server 2000。我对连接级别设置的解释是否正确？即，使用 GO 将脚本分成批处理不会限制这些 SET 选项的范围。更高版本的连接级别设置已重命名为批处理级别呢？
  2. 有没有办法取消设置？据我了解，连接级设置是三元的——即 ON、OFF 和 default，其中 default 是根据 SQL 语句的内容、实例设置、数据库设置和持久用户设置来解释的。如果我将某些内容设置为 ON，我无法撤消它，只需将其设置为 OFF 即可撤消它，因为它会掩盖默认值，如果这是之前的设置。
  3. 有什么方法可以在设置之前保存连接级别设置的状态，这样我之后可以手动恢复吗？

替代品很烂：

  1. 我可以在动态 SQL 中为索引视图包装每个创建/更改语句 - SS2K 有 4000/8000 字符限制。这将很好地限制 SET 语句的范围。
  2. 我可以制定一项政策来修复要在项目级别使用的 SET 选项，并要求所有开发人员将这些 SET 选项放在每个更改脚本的顶部以强制执行它，因为直到部署时间才能确切知道哪些更改脚本将被应用。
  3. 我可以修补 DBDeploy 本身以始终为每个更改脚本使用新连接，但这需要重新设计它处理撤消更改脚本的方式。

那么可以做什么，我该怎么做？

4

1 回答 1

0

不幸的是，我不相信有办法在您的连接中获取当前的 SET 状态。

我不使用 DBDeploy.NET，但这听起来确实像是该工具的限制。DBDeploy.NET 应该在项目元数据中（如在 Visual Studio DB 项目中）定义它随后部署的任何数据库的 SET 谓词默认值。

为了避免脚本之间的“出血”，它应该在连接到最终脚本的每个脚本之前使用这些项目级默认值自动添加 SET 语句。

拥有这种确定性方法意味着开发人员可以清楚地了解每个 SET 在其脚本执行时将处于什么状态。否则，脚本将受制于 SQL 客户端连接或服务器实例中存在的各种默认设置。

于 2011-08-08T09:14:06.477 回答