我有多个客户端通过不可靠(无线/gprs)网络连接到 SQL Server，并在几分钟内执行大量小型查询和插入。如果在此过程中网络连接中断，则整个事务将回滚并需要重新启动。由于业务需求，流程必须是事务性的(即其他客户端要么看到来自其他客户端的完整数据集，要么根本看不到)。
我希望能够检测到连接何时断开，并能够重新连接到 SQL Server 并在刚刚删除的同一事务中继续处理，并避免从头开始重新启动。目前，我在打开连接后立即使用 sp_getbindtoken，将 CommandTimeout 设置为较小的值(远小于 TCP KeepAlive)，并且如果在 ExecuteNonQuery 期间超时>，我打开与服务器的新连接，并从进程开始时使用 token 调用 sp_bindsession 。然后，我使用新连接继续处理， session 绑定(bind)到前一个处理的事务。
到目前为止，它工作得几乎完美，但根据MSDN ，此 API 已弃用，并将在 SQL Server 的 future 版本中删除。问题是:如果没有这两个命令，我如何才能获得相同的结果？有没有其他方法可以从断开的 TCP 连接中恢复事务？
编辑/更多信息:客户端应用程序在带有条形码扫描仪的 Windows CE 设备上运行。我提供设备和软件，因此我可以自由地将我需要的任何东西放在那里。 DB 由第三方托管在 protected 环境中，我和客户都无法控制它。我总共有约 50MB 的每日销售数据要发送。我可以使用 SP 来保存数据，但仍然需要传输数据，并且使用一个大参数对 SP 进行一次调用，通过 GPRS/EDGE 链路成功的机会接近 0%。
由于整个解决方案在生产环境中运行，我希望将更改保持在最低限度。与 sp_bindsession 具有相同语义的替代 API 将是完美的。
最佳答案
我只是不认为单笔交易需要约 50MB 的每日销售数据。我认为单个销售交易需要包装在 sql 交易中，但每个交易大约 1K。您确定不能在服务器上的存储过程中运行多个小事务吗？如果每个设备必须全部或全无，则通过小事务将设备加载到临时表。当设备完成后，然后在事务中使用服务器上的存储过程来刷新暂存表。或者只是在上传完成时放置一个 bool 列，然后在上传完成时在一次更新中翻转该标志。 50MB 的事务确实会破坏事务日志并锁定其他更新。
关于.net - IP 更改后重新连接已删除的 SqlConnection，而不回滚事务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8467729/