ADO.NET事宜的锁不起作用
ADO.NET事务的锁不起作用
我在ADO.NET里面这样操作事务，完全没有问题，里面的锁也起了作用，会搁置其他同时进行的进程的查询请求。
但是这样子，把中间那块拿出来，这个锁居然不起作用了！然而数据更新还是被事务正确提交了！就是锁不起作用，这个是为什么。。我搞了很久没弄明白。。。这个到底是什么情况。。
求教。。。
------解决思路----------------------
你应该仔细检查一下 ddd 方法内的代码是否有写错的情况。你这种 try...catch代码，就算是运行时出了错，也发现不出来。这种欺骗用户、领导的（让人家看不到异常提示信息）的编程习惯，往往也欺骗了自己，使得程序员自己丧失了发现问题的调试能力。
因此只能靠口头上记得自己要反复“仔细检查”来弄了，没有什么客观有效的办法来保证你写的代码的质量。因此我也从来不对写出你这种代码的程序员的产品的质量抱有任何希望。
要想写好程序，就把 try...catch 去掉。只要在最外层表现层处理异常就行了，而且也只是在release发布版本才启动，在debug版本都是去掉try...catch（或者使用“条件编译语句”去屏蔽掉它们）巴不得异常尽早跳出来好促使在开发时真正在代码中重构业务分支判断逻辑，哪有在debug版本中就胡乱写try...catch的道理？
------解决思路----------------------
写的不是很清楚，你ddd（）里面的代码顺序和原来的那“块”不同，sleep和executenonquery，根据你的思路，自己细看吧
既然写了try，就要有catch具体的输出内容，这个内容至少你自己能看懂
我在ADO.NET里面这样操作事务，完全没有问题，里面的锁也起了作用，会搁置其他同时进行的进程的查询请求。
但是这样子，把中间那块拿出来，这个锁居然不起作用了！然而数据更新还是被事务正确提交了！就是锁不起作用，这个是为什么。。我搞了很久没弄明白。。。这个到底是什么情况。。
求教。。。
------解决思路----------------------
你应该仔细检查一下 ddd 方法内的代码是否有写错的情况。你这种 try...catch代码，就算是运行时出了错，也发现不出来。这种欺骗用户、领导的（让人家看不到异常提示信息）的编程习惯，往往也欺骗了自己，使得程序员自己丧失了发现问题的调试能力。
因此只能靠口头上记得自己要反复“仔细检查”来弄了，没有什么客观有效的办法来保证你写的代码的质量。因此我也从来不对写出你这种代码的程序员的产品的质量抱有任何希望。
要想写好程序，就把 try...catch 去掉。只要在最外层表现层处理异常就行了，而且也只是在release发布版本才启动，在debug版本都是去掉try...catch（或者使用“条件编译语句”去屏蔽掉它们）巴不得异常尽早跳出来好促使在开发时真正在代码中重构业务分支判断逻辑，哪有在debug版本中就胡乱写try...catch的道理？
------解决思路----------------------
写的不是很清楚，你ddd（）里面的代码顺序和原来的那“块”不同，sleep和executenonquery，根据你的思路，自己细看吧
既然写了try，就要有catch具体的输出内容，这个内容至少你自己能看懂