本帖最后由 ypacyhero 于 2009-12-28 14:43:40 编辑

解决方案 »

  1.   

    不用,.net的间接控制和SQL本身自己控制效果是一样的.并且,.net的控制优先度低于SQL本身.
    比如如果SQL本身持有独占锁,而.net又给他指定了共享锁,那么独占锁起作用.
    楼主在.net的command对象初始化时,sql明文中有个 holdlock,那么这个其实就传输到SQL服务器,并有SQL服务器执行的,所以他的优先权要高于用.net事务对象指定的封锁等级.
      

  2.   

    楼主最好在SQL端对事务进行控制,这样最安全.用.netADO对象控制,是在不能直接访问和管理SQL时采用.
      

  3.   


    但我如果在SQL语句中没指定holdlock,我在SQL查询分析器能够执行更新呀;理应是不可以的,因为.NET中的事务已经获得了共享锁。
      

  4.   

    .NET ADO提供的“事务控制”方法,应该和DB层效果是一样的,特别你如果使用DB厂商自己的provider时,用.net中提供的方法应该更方便
      

  5.   

    “事务处理”是有生命周期的,一般都在一个相同的connection中,你的"SQL查询分析器"和你的".net程序"应该使用的不是同一个connection
      

  6.   

    我在连接A上对数据D加了共享锁T,那么如果有线程通过连接B想对数据D进行更新那应该是要等到A连接提交事务才可以吧。所以我觉得你的说法有些问题。
      

  7.   

    你没加holdlock 本身他就是可以update的
    可以直接在sql查询分析器中测试。
      

  8.   

    刚查了点资料。应该是这样:因为共享锁是在查询时加,一旦数据查询完毕,就释放了共享锁。而加了holdlock的语句,则该共享锁一直会持续到事务结束。。所以会出现上面的情况
      

  9.   

    共用锁定会在读取完资料后立即自动释放的,而且共用锁定彼此是互不相斥的,
    只有当你设定了query hint时,才会改变共用锁定释放的时间长度,如LZ提到的在查询上加 holdlock