这是在 EF 6 之前。我的公司有一个流程,可以与我们期望的所有其他客户一起工作。该过程打开到客户端数据库的连接,一次读取 1000 条记录,并将其提交到我们的数据库。对于这个客户端,我们读取并提交前 1000 条记录就好了。当它再次开始读取时,我得到“底层提供程序在打开时失败”。我知道每次读取都会打开和关闭 EF 事务,因此当它尝试重新打开连接以进行下一次读取时,它就会失败。详细信息:我们通过 VPN 连接到客户端数据库。代码流程为: connection.open() create datareader while datareader.read() get 1000 records bulk commit db.SaveChanges get next 1000 records and so on until it gets all records在第一次 SaveChanges 之后是我们得到错误的时候。任何帮助表示赞赏。
2 回答

慕莱坞森
TA贡献1810条经验 获得超4个赞
感谢大家的帮助。事实证明,丢失的连接是我们的数据库而不是客户端的。不完全确定原因,但似乎有帮助的是将我们的 BulkInsert 方法在 using 块内创建 SqlBulkCopy 对象。我们还在失败时重新建立了连接。这有点hacky,但它正在工作。

慕虎7371278
TA贡献1802条经验 获得超4个赞
在 EF6 之前,无论 DbContext 是否拥有它,它都会在被释放时关闭连接。从 EF6 开始,上下文遵循contextOwnsConnection
传递给构造函数的标志(参见此处)。从您的伪代码中不清楚您如何实例化连接和上下文,因此假设您在循环中创建上下文并传递打开的连接。如果是这种情况,您有几个选择:
升级到 EF6,或
仅对所有保存使用一个 DbContext,或者
将所有记录加载到内存中,并在其自己的 DbContext 中以块的形式处理它们,或者
分块加载,分块处理
如果出于性能原因避免使用相同的上下文进行处理,则可以使用 .AsNoTracking()。MSDN 上有一篇关于 EF 性能调整的文章,以防您需要更多。
- 2 回答
- 0 关注
- 175 浏览
添加回答
举报
0/150
提交
取消