我有多个客户端通过不可靠的(无线/ gprs)网络连接到SQL Server,并在几分钟内执行大量的小型查询和插入操作。 如果在此过程中网络连接断开,则整个事务将回滚并需要重新启动。 由于业务需求,流程必须是事务性的(即,其他客户只能从其他客户那里看到完整的数据集,或者根本看不到它)。
我希望能够检测到何时断开连接,并能够重新连接到SQL Server,并在刚刚删除的同一事务中继续进行处理,并避免从头开始重新启动。 目前,我在打开连接后立即使用sp_getbindtoken
,将CommandTimeout
设置为较小的值(比TCP KeepAlive小得多),如果在ExecuteNonQuery
期间超时,则打开与服务器的新连接,并从进程开始用令牌调用sp_bindsession
。 然后,我使用与会话绑定到上一流程的事务的新连接继续流程。
到目前为止,它几乎可以完美运行,但是据MSDN称 ,该API已被弃用,并将在以后的SQL Server版本中删除。 问题是:如果没有这两个命令,如何获得相同的结果? 还有其他方法可以从断开的TCP连接中恢复事务吗?
编辑/进一步信息:客户端应用程序在带有条形码扫描仪的Windows CE设备上运行。 我同时提供设备和软件,因此我可以随意放置任何需要的东西。 DB由第三方托管在受保护的环境中,我和客户都无法控制它。 我总共要发送约50MB的每日销售数据。 我可以使用SP来保存数据,但是仍然必须传输它,并且使用一个大参数对SP的一次调用在GPRS / EDGE链路上成功的可能性接近0%。
由于整个解决方案都在生产环境中工作,因此我希望将更改降至最低。 具有与sp_bindsession
相同语义的替代API将是完美的。