想象一下这个场景,你正在更新一些遗留的Sybase代码,并遇到了一个游标。存储过程在#temporary表中建立了一个结果集,这个结果集已经全部准备好了,除了其中一列不是很好的人类可读性,是一个字母数字代码。
我们需要做的是,找出这个代码可能的不同值,调用另一个存储过程来交叉引用这些离散的值,然后用新解密的值更新结果集。
declare c_lookup_codes for
select distinct lookup_code
from #workinprogress
while(1=1)
begin
fetch c_lookup_codes into @lookup_code
if @@sqlstatus<>0
begin
break
end
exec proc_code_xref @lookup_code @xref_code OUTPUT
update #workinprogress
set xref = @xref_code
where lookup_code = @lookup_code
end
现在,虽然这可能会让一些人心有余悸,但它确实有效。我的问题是,如何才能最好地避免这种事情的发生?
_NB: 在这个例子中,你也可以想象结果集有50万行,并且有100个不同的look_up_code值,最后,不可能有一个包含xref值的表,因为proc_code_xref的逻辑太玄乎了。
如果你想取出游标,你必须有一个XRef表。假设你知道100个不同的查找值(并且它们是静态的),通过调用proc_code_xref 100次并将结果插入到一个表中,就可以很简单地生成一个表
除非你愿意重复xref proc中的代码,否则没有办法避免使用游标。
他们说,如果你必须使用游标,那么,你一定是做错了什么;-)这里有一个不使用游标的解决方案。
declare @lookup_code char(8)
select distinct lookup_code
into #lookup_codes
from #workinprogress
while 1=1
begin
select @lookup_code = lookup_code from #lookup_codes
if @@rowcount = 0 break
exec proc_code_xref @lookup_code @xref_code OUTPUT
delete #lookup_codes
where lookup_code = @lookup_code
end