使用Local FAST_FORWARD定义游标，出现游标循环取值错误

Question

你的sql版本?
贴一下你出错的存储过程，尤其是非业务逻辑的那一部分

Answer 1

数据库：sql2000SELECT AutoID, List_ID, Stor_Syb
FROM BillProd 
where Bill_ID=@i_BillID
order by AutoIDdeclare cur_tmp cursor Local FAST_FORWARD for 
SELECT AutoID, List_ID, Stor_Syb
FROM BillProd 
where Bill_ID=@i_BillID
order by AutoID
open cur_tmp
fetch next from cur_tmp into @PHisID, @BillList_ID, @Stor_Syb
while @@FETCH_STATUS=0
beginselect '@Stor_Syb', @Stor_Syb...... fetch next from cur_tmp into @PHisID, @BillList_ID, @Stor_Syb
end
Close cur_tmp
deallocate cur_tmp-----------------------------------------------------------------------运行显示：
AutoID  List_ID  Stor_Syb
2366 618  2(无列名)    (无列名)
@Stor_Syb   2 (无列名)    (无列名)
@Stor_Syb   2

Answer 2

--TRY
declare cur_tmp cursor  FAST_FORWARD for 

Answer 3

没2000环境，测试不到.试下:
declare cur_tmp cursor STATIC LOCAL FAST_FORWARD for 
    SELECT AutoID, List_ID, Stor_Syb 
    FROM BillProd 
    where Bill_ID=@i_BillID 
    order by AutoID 

Answer 4

奇怪，在2005下，经过测试，结果都是一样的。declare cur cursor for...默认就是：declare cur cursor forword_only for...
forword_only/scroll 两者只能选其一，前者只能从前往后用next读，后者则无此限制。而declare cur cursor fast_forword for...，
fast_forword包含forward_only,read_only的含义，
这意味着该游标只能从前往后用next读，并且不能用于更新底层表的数据。由此，怀疑LZ的错误是业务逻辑导致，或者是2000对这些扩展的语法支持得并不是很好。
建议LZ建立一个更纯净的环境来测试一下。

Answer 5

业务逻辑应该没有问题，因为换成scroll，业务处理结果都是对的

Answer 6

declare cur_tmp cursor Local FAST_FORWARD for 这种是动态游标, 会应用数据变化的内容, 所以可能会导致重复, 如果你要避免这种情况, 定义静态的就可以了
declare cur_tmp cursor Local FAST_FORWARD STATIC
for 

Answer 7

参考我的blog中的相关内容选择合适的游标类型
http://blog.csdn.net/zjcxc/archive/2007/05/12/1606109.aspx认识静态与动态游标
http://blog.csdn.net/zjcxc/archive/2007/05/12/1606103.aspx游标类型产生的数据检索问题
http://blog.csdn.net/zjcxc/archive/2007/05/12/1605777.aspx

Answer 8

不能这样用吧。FAST_FORWARD 是动态游标，跟STATIC关键字是冲突的，两者只能选一。

Answer 9

试下: SQL codedeclare cur_tmp cursor STATIC LOCAL FAST_FORWARD for 
    SELECT AutoID, List_ID, Stor_Syb 
    FROM BillProd 
    where Bill_ID=@i_BillID 
    order by AutoID ---------------
用了FAST_FORWARD，是不能同时使用STATIC的

Answer 10

因为使用了order-by子句产生了内部的工作表产生一个keyset型的游标
KEYSET指定在開啟資料指標時，修正資料指標中之資料列的成員資格和順序。用來一識別資料列的索引鍵集會建立在 tempdb 的 keyset 資料表中。 附註：  
如果查詢所參考的資料表中至少有一個沒有唯一的索引鍵，則索引鍵集資料指標會轉換為靜態資料指標。
 
當資料指標擁有者捲動資料指標時，基底資料表中非索引鍵的變更，不論是資料指標擁有者所進行的變更，或其他使用者所認可的變更，都是可見的。其他使用者的插入便不可見 (無法利用 Transact-SQL 伺服器資料指標來插入)。如果刪除了資料列，試圖提取這個資料列會傳回 @@FETCH_STATUS -2。從資料指標之外更新索引鍵值，類似於先刪除舊資料列，再插入新資料列。含有新值的資料列不可見，試圖提取有舊值的資料列會傳回 @@FETCH_STATUS -2。如果更新是藉由指定 WHERE CURRENT OF 子句透過資料指標執行，新值便可見。

Answer 11

请问游标定义为：FORWARD_ONLY READ_ONLY STATIC，是不是为最快捷的方式？我原来查资料说的FAST_FORWARD，好像是速度最快的。现在表中AutoID字段为主键，类型是标示，索引clustered。

Answer 12

只读、只往前倦取资料，这种游标应该是最快的。FAST_FORWARD说是内部做了优化，但具体不知道是怎么体现。总体来说，若是资料的笔数很多，那不管什么类型的游标，效能都不会好到哪去。

Answer 13

把order by AutoID 去掉，再測

Answer 14

我现在使用：Local FORWARD_ONLY READ_ONLY STATIC结果就对了

Answer 15

FORWARD ONLY READONLY 代替 FAST_FORWARD

Answer 16

只要是不管游标内容在过程中是否有变化，应该直接使用Local FORWARD_ONLY READ_ONLY STATIC 这种方式就可以了吧？----------------
把order by AutoID 去掉，再測这种还是不对，老样子，还是重复了

Answer 17

STATIC 和 FAST_FORWARD 資料指標的預設值是 READ_ONLY。DYNAMIC 和 KEYSET 資料指標的預設值是 OPTIMISTIC。
如鄒老大改為 
FAST_FORWARD應該可以