我的SQL连接字符串中是否需要Enlist = False？

Question

我们有一个使用ASP.NET和SQL Server 2008构建的大型网站，并且可以通过向连接字符串添加Enlist=False来解决一些连接问题（根据其他StackOverflow问题以及其他问题） ，覆盖默认值True。

我读到了有关分布式交易的信息，我认为我们并未使用它们，但我仍然不确定是否在我们的实时服务器上进行此更改。也许它没有任何区别！我的基本问题是：

当我们不在ASP.NET代码中使用任何事务时，是否要将Enlist=False添加到我的连接字符串中？

有人谈到在不久的将来向一两个我们的SQL存储过程添加事务 - 简单的BEGIN TRAN和COMMIT TRAN类的东西 - 但是在ASP.NET中我们肯定不会有事务。 （我们也不使用DAAB。）

Answer 1

我想我理解您的问题，并希望分享一些经验。

第1部分

我正在分发一个ASP.NET应用程序，该应用程序基本上不需要我自己的事务。该应用程序既可以在私人笔记本电脑上运行，也可以在企业框架内，具有分布式服务的虚拟服务器上运行。

大约两年前，我遇到了在Enlist=False中设置web.config以避免出现异常的情况。

这一直很有效-因此，我的答案的第一部分是，如果不需要事务，分布式事务或其他操作，则添加Enlist=False不会对您造成伤害。

第2部分

同时，我添加了很多导入功能。导入时，可能会创建数百个新的数据库记录。在这里，对我来说至关重要的是，如果出现问题，请回滚所有内容。由于我无法创建复杂的SQL回滚（即在导入时创建单个SQL回滚命令），因此我不得不使用事务。

由于导入过程相当复杂，所以我最终得到了混合代码：

• 某些代码正在使用DbContext：MyEntities.Add(xx)，...，dbContext.SaveChanges()
• 某些代码使用SqlCommand使用SQL。

因此，我不得不将这些动作合并到某个事务框架中-事实证明TransactionScope是正确而美好的事情。但是，我花了一些时间来了解TransactionScope仅在未设置Enlist=False 的情况下才有效。嵌套的操作根本不会加入事务框架，否则避免使用Complete()进行回滚不会产生任何影响。

现在，我继续使用Enlist=False作为我的应用程序标准，但是对于导入，我创建了一个临时DbContext，其连接字符串已修改。您知道了：

...
connectionString = Regex.Replace(originalString, @"\s*;\s*Enlist\s*=\s*False\s*", "", RegexOptions.IgnoreCase);
...

这很容易实现，因为我提供了在数据库之间进行选择的可能性，而且无论如何我都必须动态获取连接字符串。效果很好，而且我完全可以控制在何处定位。

因此，我的答案的第二部分是，如果以后遇到问题，可以偶尔删除Enlist=False。

我正在使用目标ASP.NET Framework 4.5版进行构建。