C#技术求助：The underlying provider failed on Open，TransactionScope已完成

我来帮你拆解这个问题——虽然你自己的代码片段里没直接用到TransactionScope，但这个错误的核心是：当前应用上下文里存在一个已经被完成（提交/回滚）的事务范围，而Entity Framework尝试在这个已失效的事务上下文下去打开数据库连接。下面是几个大概率的原因和对应的排查/解决方法：

1. 上层调用链隐式使用了TransactionScope #

你的代码GetGlobalSettingValues()可能被某个上层方法调用，而上层方法里用到了TransactionScope，但没有正确处理事务的生命周期：比如提前调用了scope.Complete()或者在事务范围using块外执行了数据库操作。

举个典型的错误场景：

using (var scope = new TransactionScope())
{
    // 执行一些操作后，提前完成事务
    scope.Complete();
    // 这里调用你的方法，此时事务已经结束，但EF仍会尝试在事务上下文里获取连接
    Settings.GetGlobalSettingValues();
}

解决方法：

• 梳理调用GetGlobalSettingValues()的所有上层逻辑，确保数据库操作都在TransactionScope的活跃期（using块内，且未调用Complete()）执行；
• 检查是否有代码在事务Dispose后还复用了关联的资源。

2. EF上下文的生命周期或共享问题 #

如果你的ManagementDbContext被多个操作共享（比如依赖注入时注册为单例），或者之前的操作触发了事务但上下文未被正确释放，就可能导致残留的无效事务状态。

解决方法：

• 确认你当前用using包裹DbRepository的方式是正确的（保证每个操作都用独立的上下文实例），但要排查是否有其他地方复用了同一个上下文；
• 如果用了依赖注入，检查上下文的生命周期配置（建议用Scoped而非Singleton，避免跨请求/操作共享事务状态）。

3. 第三方组件或框架隐式创建了TransactionScope #

有些第三方库（比如日志、缓存、权限验证组件）或者框架扩展可能在幕后使用了TransactionScope，但没有正确清理，导致事务状态残留。

解决方法：

• 排查当前代码执行链中引入的第三方组件，看是否有涉及事务的逻辑；
• 应急排查：可以在你的数据库操作前手动清理当前残留的事务（注意：这是临时排查手段，不要直接作为生产解决方案，避免影响正常事务）：

// 在你的查询代码前添加
if (System.Transactions.Transaction.Current != null)
{
    System.Transactions.Transaction.Current.Dispose();
}

using (var dbRepository = new DbRepository<ManagementDbContext>()) { 
    listGlobalSettingValue = dbRepository.Select<GlobalSettingValue>().Include(x => x.SettingDefinition).ToList(); 
}

4. 数据库连接池的残留事务关联 #

错误栈里提到了DbConnectionPool.GetFromTransactedPool，说明连接池中的某个连接被关联到了已完成的事务。当EF尝试复用这个连接时，就会触发错误。

解决方法：

• 作为临时排查，可以重启应用清空连接池，看是否能暂时解决问题；
• 可以尝试在连接字符串中添加Enlist=false（禁用连接自动登记到事务），但这会影响正常的事务场景，仅建议用于定位问题根源。

内容的提问来源于stack exchange，提问作者M Hilmi Koca