怎样防止一条纪录被多个用户同时修改

Question

sql server2000数据库本身自动管理的.你可以考虑用户在读取其表时，禁止他人读表的设计。

Answer 1

/******** 局域网中的所有SQL服务器
EXEC MASTER..XP_CMDSHELL 'OSQL -L'  /**********  加锁   ***************
设table1(A,B,C)
A    B    C
a1   b1   c1
a2   b2   c2
a3   b3   c31）排它锁
新建两个连接
在第一个连接中执行以下语句
begin tran
   update table1
   set A='aa'
   where B='b2'
   waitfor delay '00:00:30'  --等待30秒
commit tran
在第二个连接中执行以下语句
begin tran
   select * from table1
   where B='b2'   
commit tran若同时执行上述两个语句，则select查询必须等待update执行完毕才能执行即要等待30秒2）共享锁
在第一个连接中执行以下语句
begin tran
   select * from table1 holdlock -holdlock人为加锁
   where B='b2' 
   waitfor delay '00:00:30'  --等待30秒
commit tran在第二个连接中执行以下语句
begin tran
   select A,C from table1
   where B='b2' 
   update table1
   set A='aa'
   where B='b2'   
commit tran若同时执行上述两个语句，则第二个连接中的select查询可以执行
而update必须等待第一个连接中的共享锁结束后才能执行 即要等待30秒3）死锁
增设table2(D,E)
D    E
d1   e1
d2   e2
在第一个连接中执行以下语句
begin tran
   update table1
   set A='aa'
   where B='b2' 
   waitfor  delay '00:00:30'
   update table2
   set D='d5'
   where E='e1' 
commit tran
   
在第二个连接中执行以下语句
begin tran
   update table2
   set D='d5'
   where E='e1' 
   waitfor  delay '00:00:10'
   update table1
   set A='aa'
   where B='b2'  
commit tran同时执行，系统会检测出死锁，并中止进程
--------------------------------------------------------------
SET IMPLICIT_TRANSACTIONS  ON --用户每次必须显式提交或回滚。否则当用户断开连接时,
                              --事务及其所包含的所有数据更改将回滚SET IMPLICIT_TRANSACTIONS  OFF --自动提交模式。在自动提交模式下，如果各个语句成功
                               --完成则提交。

Answer 2

搂主给咱用SQL Server作出一个“一条记录被多人同时修改”的例子来！？数据库中是不会的。但是，客户软件却可能这样。比如，两个“取款”终端，同时对同一个账户取钱，其中一个操作员可能发现刚刚还是“余额10000元”呢，怎么刚取了500元，余额就显示为9000元了？这个“错误”不是数据库的错，是开发客户机的程序员台“随意”了，没有去分析用户的心理。大部分客户端软件都存在这个问题。不解决它，给用户“自由”的操作空间，也很好。要解决它，技术上，用“时间戳”等方式也非常简单方便，只是操作用户受但的限制（另一方面也可以说是认真负责地核对）也多一些。

Answer 3

三层结构中间层就可以解决这个问题啊
客户端只是发请求（可能只是一个Socket请求）
然后中间层根据业务建立相应队列进行执行
可以在中间层设定队列长度以及超时
这样客户端就不会等很长时间

Answer 4

对单行记录锁定更新，有没有更好的方法呢？ 比如我的业务如下：
   
    我定义有一批紧俏商品，每类商品规定了限量，对应表如下 T_LimitWare (WareCode,LimitNum) 
 数据如：     001        20
              002        100
               ……
  当抢购商品的时候，系统首先从次表中按商品编码（WareCode)来检测仓库中还存在的数量（LimitNum)，当购买量小于对应商品的 LimitNum时候，交易成功（此时应该更改LimitNum的值），否则失败。当此类紧俏商品销售完后，则对应商品记录从此表中删除！  因为业务实际情况，抢购总是发生在每一天的特定时候，而且客户抢购商品的先后顺序也类似（比如首先看001还有没有库存，如果没有则查看002……），也就是说对此表中同一条记录的并发访问情况在抢购时候非常普遍，而且因为终端很多（50个以上），造成此时候系统的访问速度非常的慢   对以上描述的问题，如果单单靠数据库的锁来解决并发以保证数据上的正确，而因为锁而又导致系统此时的串行运行……系统运行速度让操作员也让客户无法接受，请教有没有好的是方法或者设计，来解决此问题……

Answer 5

“抢购问题”的一种实现方法：原则就是：
1. 立即出库。
2. 出库不等于销售。
3. 销售不成立则抢购品返库。具体地说，就是：设置“待销售库”用来保存“哪一台POS抢占了某些商品”的资料。POS开始交易时，将抢购品出库到“待销售库”中，交易成交时真正记录销售并移出货品，交易作废（或者超时被强制作废）时将货品返回仓库。这个设计，中间环节不需要加锁，可以有更高的系统吞吐量，就是我说的“利用业务原则将这些事务在逻辑上联系起来”而不需要真正做一个“硬性的”事务。

Answer 6

 to :w_rose(w_rose)
  
   ……交易成交时真正记录销售并移出货品，交易作废（或者超时被强制作废）时将货品返回仓库 
   执行此真正的交易操作时候还不照样需要经过数据（库存）的校验以及记录的更新吗？好象还是没有解决问题八……       或许没理解 w_rose(w_rose)的意思

Answer 7

对“抢购问题” ，  大家看这样行不行
 
    当取出每个POS申请抢购数量的时候不做数量的判断，即为出库而非销售。而后中间层程序控制每隔一段时间，提交一次对抢购商品表的检索与更新。比如在一个时间段内，有5个POS提交了对对应商品的抢购需求，我对5个POS终端的同一商品的数量进行累加，而后一次性的到数据表中进行数量的判断，如果请求量小于剩余库存则交易成功（一起提交5个POS端的请求），如过总数量超过了总的库存，则回滚这5个所有的请求，当然复杂点的比如可以按从请求数量的从大到小来单个取消这5个中的某一个或多个请求（按实际的抢购申请量和库存量）……
  这样可以大大的减低对同一数据表同一行数据的并发请求而导致队列的串行时间消耗……
   当然这样做起来肯定会比较麻烦，特别是时间间隔的控制和对多个用户进行一个事物的封装 ，但我想应该可以实现
  大家讨论一下，可行不可行！？

Answer 8

事实上，我想没有一个零售店的POS是这样控制的。这样控制更适合于“批发”店。批发企业的销售是“大宗”的，并且POS与库房相隔很远，很容易在开提货票的数量上出错。对于零售店，发生“销售数量比库存数量多”的情况很少，后果也不严重。

Answer 9

对表修改时，使用独占锁（表或行锁tablelockX\rowlock）
update tablename 锁
set col1=数值
where 条件增加删除情况一样

Answer 10

你这里的用户是不是Login?
大多数的"用户"不是login!(多个连接使用同一个 login)
如果你的应用确实不允许多个连接客户端同时修改
我有一个利用"全局临时表"特性的解决方案:
太晚了!
明天继续...

Answer 11

用beigin tran ...commit tran 最短语句放到锁里。
瘫了比帐错了好吧