SQL Server 2000 - 如何恢复连接级别设置的先前状态

时间:2010-06-30 15:09:53

标签: sql-server tsql sql-server-2000 dbdeploy

我在我的T-SQL代码库中使用DBDeploy.NET进行变更控制管理。 DBDeploy由开发人员负责维护一组编号的更改脚本。当触发部署(通过NAnt)时,DBDeploy会查看更改日志表并确定需要执行哪些修补程序才能使实例更新。

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

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

    1. 我可以为动态SQL中的索引视图包装每个create / alter语句 - 它对SS2K的限制为4000/8000 char。这将很好地限制SET语句的范围。
    2. 我可以制定修改SET选项的政策,以便在项目级别使用,并要求所有开发人员将这些SET选项放在每个更改脚本的顶部以强制执行它,因为在部署时间之前没有确切的说明将应用更改脚本。
    3. 我可以修补DBDeploy本身以始终为每个更改脚本使用新连接,但这需要重新设计它处理撤消更改脚本的方式。
    4. 那么可以做些什么,我该怎么办?

1 个答案:

答案 0 :(得分:0)

不幸的是,我不相信有一种方法可以在您的连接中获取当前的SET状态。

我不使用DBDeploy.NET,但这听起来明显像是工具的限制。 DBDeploy.NET应在项目元数据中定义(如在Visual Studio DB项目中)SET谓词默认应该为随后部署的任何数据库定义的内容。

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

拥有这种确定性方法意味着开发人员可以清楚这些SET在脚本执行时将处于什么状态。否则,脚本将受SQL客户端连接或服务器实例中存在的各种默认值的影响。