我有多个客户端通过不可靠(无线/ gprs)网络连接到SQL Server,并在几分钟内执行大量的小查询和插入.如果在此过程中网络连接中断,则会回滚整个事务并需要重新启动.由于业务需求,流程必须是事务性的(即其他客户端看到来自其他客户端的完整数据集或者根本看不到它).

我希望能够检测连接何时中断并能够重新连接到SQL Server并继续处理刚刚删除的同一事务,并避免从一开始就重新启动.目前我在打开连接后立即使用sp_getbindtoken,将CommandTimeout设置为小值(远小于TCP KeepAlive),如果在ExecuteNonQuery期间出现超时,我打开与服务器的新连接,并从进程开始使用令牌调用sp_bindsession.然后我继续使用绑定到先前进程’事务的会话的新连接进行处理.

到目前为止,它几乎完美地工作,但根据MSDN,这个API已被弃用,将在SQL Server的未来版本中删除.问题是：如果没有这两个命令,我怎样才能获得相同的结果？是否还有其他方法可以从丢弃的TCP连接恢复事务？

编辑/更多信息：客户端应用程序在带有条形码扫描仪的Windows CE设备上运行.我提供设备和软件,所以我可以随意放置任何我需要的东西.数据库由第三方托管在受保护的环境中,我和客户都无法控制它.我总共要发送约50MB的每日销售数据.我可以使用SP来保存数据,但它仍然必须被传输,并且使用一个大参数对SP的一次调用在GPRS / EDGE链路上成功的几率接近0％.

由于整个解决方案在生产环境中工作,我希望将更改保持在最低限度.与sp_bindsession具有相同语义的替代API将是完美的.

最佳答案 我只是不买这个〜50MB的每日销售数据需要在一次交易中.我买单个sales-tansactions需要包含在sql-transaction中,但那些更像是每个1K.您确定无法在存储过程中在服务器上运行多个小事务吗？如果它必须是来自每个设备的全部或全部,则通过小事务将设备加载到临时表.完成设备后,在事务中使用服务器上的存储过程来刷新登台表.或者只是在完成上传时放置一个布尔列,然后在上传完成时在单个更新中翻转该标志.一个50MB的交易真的会破坏交易日志并锁定其他更新.