在具有SQL Server故障转移群集或镜像的环境中，您更喜欢如何处理错误？似乎有两种选择：
每种方法都有其优点和缺点。我与之合作的大多数商店都做＃1，但其中许多商店也没有遵循严格的交易边界，而且在我看来如果发生故障，他们会让自己陷入困境。即便如此，我也很难将它们转化为＃2，这也应该会带来更好的用户体验（一次捕获是发生故障转移时潜在的长时间延迟）。
任何论据都会受到赞赏。如果您使用第二种方法，您是否有一个有助于简化实施的标准包装器？无论哪种方式，您如何构建代码以避免诸如与失败的命令中缺乏幂等性相关的问题？
答案 0 :(得分：0)
2号可能是无限循环。如果它与网络相关，或者本地PC需要重启，或者其他什么呢？
当然，数字1对用户来说很烦人。
如果您只允许通过网站进行访问，那么除非故障转移发生在呼叫中，否则您永远不会看到错误。对我们来说，这是不可能的，如果没有最终用户意识到我们已经失败了。
在现实生活中，您可能没有在Web服务器上使用干净的DAL。您可能有连接（大多数财务）或WinForms连接保持打开的Excel工作表，因此您只有一个选项。
故障转移应该只需要几秒钟。如果数据库恢复需要更多，那么无论如何都会有更大的问题。如果经常发生这种事情就必须考虑处理它，那么......
总而言之，很少会发生您想知道的事情，而且数字1会更好。 IMHO。