背景
DSC Pull模式下，DSC Node上LCM在执行Job前会请求Pull Server上部署的PSDSCPullServer.svc服务，在StatusReport中插入一条数据，主键为jobid
等本次Job执行完成（成功或者失败），会更新该jobid对应的数据。
架构
问题
新搭建的UAT环境中，发现job跑完之后，并未更新StatusReport表中对应的数据。
对方提供的数据非常典型，2台DSC Node，一台正常，另外一台有上述问题。
插一句
其实，DSC这一套是微软提供的黑盒子，出了问题，重新仔细安装一遍基本能解决100%的问题。
分析
- 2台DSC Node都能在job开始前插入数据
说明PSDSCPullServer.svc服务正常
- 其中1台正常，而另外一台不正常
如果2个请求都由同1台Pull Server处理，不大可能发生这种问题
所以，更新操作的请求分别打到了2太负载的Pull Server上，而其中一台server上的服务有问题。
验证Access的link table
根据以往的经验，多半是Access到SQLServer出了问题
我们打开2台Pull Server上的Access，任意修改StatusReport表的某个数据，在SQLServer中检查是否同步了
我修改的是jobid列
- DSC Pull Server 01上修改，SQLServer有同步数据
- DSC Pull Server 02上修改，提示：Recordset is not updatable
why？是不是这就是根本原因啊！先怀疑上你。
查看日志
检查2台负载的Pull Server的IIS日志，发现请求确实分别打到了2台Pull Server上，更新失败的那台DSC Node的请求打到了DSC Pull Server 02上了，不过HTTP响应都是200。
响应200就一定是操作成功吗？
在之前文章中，我们模拟发送过SendReport请求，我也吐槽过这个接口的设计：操作失败也会响应200，Message还提示Success，可以说是巨坑了
手动发送请求
-
Nginx只负载DSC Pull Server 01，发送请求，创建数据，成功；
再次发送请求，更新数据，成功 -
Nginx只负载DSC Pull Server 02，发送请求，创建数据，成功；
再次发送请求，更新数据，失败
还用说什么吗？DSC Pull Server 02 有问题，排除是程序错误，那就是Access的问题了。
转换问题
那么，到这里，问题就变成这样了：为什么Access数据库可以插入而不能更新呢？
一旦把业务问题转换成业务无关的技术问题，问题基本就解决了90%
解决
很容易就找到答案：你的数据库表没有设置主键。
很好，让我检查一下，是不是真有哪个小可爱没有设置主键，一看还真是。
至于其中的原因，一言难尽，也不是重点
原文地址：http://www.cnblogs.com/talentzemin/p/16814882.html
