22,297
社区成员
发帖
与我相关
我的任务
分享sql server 2000 数据会偶尔莫名其妙丢失一条
我的客户端程序在第一个岗位输入数据前，会先用存储过程向一个表中插入一行，并返回唯一的一个编码，例如：201304040001、201304040002...，输入数据结束后，利用返回的编码将客户端输入的数据对这行进行更新。
到下一个岗位再利用这个编码第二次更新几个字段，F1，F2...
然后过一段时间本岗位会利用这个编码第三次更新几个其他字段F5,F8...
****但是，在第三次想再更新几个其他字段F5,F8...的时候，这行数据突然没有了。****
让人非常头疼，请问有人遇见过类似的问题吗？
到下一个岗位再利用这个编码第二次更新几个字段，F1，F2...
然后过一段时间本岗位会利用这个编码第三次更新几个其他字段F5,F8...
****但是，在第三次想再更新几个其他字段F5,F8...的时候，这行数据突然没有了。****
让人非常头疼，请问有人遇见过类似的问题吗？
...全文
请发表友善的回复…
发表回复
iamtsfw 2013-04-06
- 打赏
- 举报
请您帮我看看我生成ID的存储过程好吗？
--获取新id
CREATE PROCEDURE prBuyMakeNewBuyID
@strToday varchar(50)
AS
set transaction isolation level serializable
begin transaction
declare @maxid varchar(50)
declare @tmpnum float
select @tmpnum=convert(float,right(isnull(max(id), @strToday+'0000'),4)) from tbbuybuys where left(id,8)=@strToday
select @tmpnum=@tmpnum+1
if @tmpnum<=9 and @tmpnum>=0
select @maxid=@strToday + '000' + convert(varchar(50),@tmpnum)
if @tmpnum<=99 and @tmpnum>=10
select @maxid=@strToday + '00' + convert(varchar(50),@tmpnum)
if @tmpnum<=999 and @tmpnum>=100
select @maxid=@strToday + '0' + convert(varchar(50),@tmpnum)
if @tmpnum<=9999 and @tmpnum>=1000
select @maxid=@strToday + convert(varchar(50),@tmpnum)
declare @province varchar(100)
declare @city varchar(100)
declare @county varchar(100)
declare @company varchar(100)
declare @allownowsubweight int
select @province=province,@city=city,@county=county, @company=company from tbcommcompany
select @allownowsubweight=allownowsubweight from tbBuyControlArgs
if @allownowsubweight=1
begin
insert into tbbuybuys (id,assaylock,totalweightlock,carweightlock,nowsubweightlock,calclock, province,city,county1,company,carweightmicrochange,isup,othermark) values(@maxid,0,0,0,0,0,@province,@city,@county,@company,0,'未上传',0)
end
else
begin
insert into tbbuybuys (id,assaylock,totalweightlock,carweightlock,nowsubweightlock,calclock,province,city,county1,company,carweightmicrochange,isup,harlamount1,harlweight,meshamount1,meshweight,packsubweight,nowsubweight,othermark) values(@maxid,0,0,0,1,0,@province,@city,@county,@company,0,'未上传',0,0,0,0,0,0,0)
end
select @maxid
commit transaction
GO
SQL77 2013-04-06
- 打赏
- 举报
还要看你的事务隔离级别.如果是读已提交.第二岗位还能读就是保存成功了.
iamtsfw 2013-04-06
- 打赏
- 举报
您说的太对了，可能是第一个岗位进行了更改，我刚才也兴冲冲地去看了自己程序里的操作日志，但是失望的是第一个岗位没有修改这张单据的数据，而且如果第一个岗位修改的话，第二个岗位做的更新应该还在啊，我们发现第二个岗位做的更新也没有了，说明确实是单据丢失了。
SQL77 2013-04-06
- 打赏
- 举报
日志你可以备份啊.待下次出现问题的时候.可以日志查看是何原因.
iamtsfw 2013-04-06
- 打赏
- 举报
我还考虑是否是因为并发造成的丢失，因为有多个岗位同时查询，插入，更新，但是：我的第一个岗位的插入操作是用事务提交的，返回的编码也从未出现过错误，而且第二个岗位能看到这张单子，就说明成功插入了，除非sql server使用了延时写入技术，造成第二个岗位看到的是服务器内存里的内容，但是没有停电啊，所以这也不能说通为什么丢失这行数据啊。
SQL77 2013-04-06
- 打赏
- 举报
不客气
你这个很大可能是由于并发问题造成数据问题.你可以单独TRACE那几个表的操作情况.
主要还得根据你的实际情况去琢磨看是哪一块可能造成数据删除(也有可能是更改)
iamtsfw 2013-04-06
- 打赏
- 举报
感谢mvp的帮助
iamtsfw 2013-04-06
- 打赏
- 举报
非常遗憾的就是，我拿到日志的时间比较晚，大约比发生故障的时间晚了5个小时，发现里面只保留了最近三个小时的日志，没有找到有价值的任何东西。
iamtsfw 2013-04-06
- 打赏
- 举报
首先感谢你的回复。
补充：
以前仅仅遇到在网络非常卡的情况下，第一个岗位进行保存和打印操作后，能正常出单据（先保存后打印，未提示保存失败），但是拿着单据到第二个岗位的时候，数据库中这行数据消失了，我们解决网络的问题后，问题没有了，但是又出现这种莫名其妙的问题了，因为这次是第二个岗位能看到单据，编辑第一次后，过段时间后再编辑第二次时，发现单据不见了，但是没有发生过编辑第二次后单据消失的情况。
SQL77 2013-04-06
- 打赏
- 举报
你是SQL2K可以利用LOG 查看器.(如果你日志OK的话)可以查看得到DEL删除的记录
iamtsfw 2013-04-06
- 打赏
- 举报
因为我不在出问题的现场，所以确实不能确定是否标记成功了，因为标记未成功，第一个岗位确实能够删除。
SQL77 2013-04-06
- 打赏
- 举报
这个就要你自己去确定了,你标志加成功了???如果没主动删除 不可能会自动没了的.
iamtsfw 2013-04-06
- 打赏
- 举报
补充，我的第二个岗位写入数据后，会加入一个锁定标志，就除了管理员外，任何人都不能删除了。我询问管理员，他说未做任何删除操作。
SQL77 2013-04-06
- 打赏
- 举报
你这应该被删除了吧
SQL77 2013-04-06
- 打赏
- 举报
select @tmpnum=convert(float,right(isnull(max(id), @strToday+'0000'),4)) from tbbuybuys where left(id,8)=@strToday
1.你的事务隔离级别改了可能很影响并发量的
2.where left(id,8)=@strToday-- 这里你看看应该改成 ID LIKE @strToday+'%'这样的写法来利用索引.减少对表的锁定
3.
if @tmpnum<=9 and @tmpnum>=0
select @maxid=@strToday + '000' + convert(varchar(50),@tmpnum)
if @tmpnum<=99 and @tmpnum>=10
select @maxid=@strToday + '00' + convert(varchar(50),@tmpnum)
if @tmpnum<=999 and @tmpnum>=100
select @maxid=@strToday + '0' + convert(varchar(50),@tmpnum)
if @tmpnum<=9999 and @tmpnum>=1000
select @maxid=@strToday + convert(varchar(50),@tmpnum)
这一段应该可以直接改成RIGHT('0000'+convert(varchar(50),@tmpnum),4)
呵呵.那时候在忙...以上是一些建议.
