February 11, 2005 at 4:01 pm
Does anyone know what could cause a cursor to continue to fetch the same row over and over again?
I have a cursor declared with dynamic sql. The cursor is opened, an update is done using dynamic sql, and then moved to the next row in the cursor. The problem I'm having is the cursor never moves to the next row, it continues to fetch the same row for infinity. If I remove the update and just print the dynamic sql, the statements looks perfect and run as intended when cut and pasted into a new query window.
What can cause the "fetch next" to continue to return the same row?
Here is some of the code - I don't know how much help it is not in context:
set @sql = 'declare muCursor cursor fast_forward for select sku, markup, id_cont from ItemPrice_Store' + isnull( @ConditionClause, '' )
exec (@sql)
set @rows = 0
open muCursor
while (0=0) begin
fetch next from muCursor into @sku, @markup, @id_cont
if @@fetch_status <> 0 break
if @markup is null continue
select @sql = 'update ItemPrice_Store set pluprice = ' + formula + ' where sku = ''' + @sku + ''' and id_cont = ' + ltrim(str(@id_cont)) from markup where markup = @markup
exec (@sql)
set @rows = @rows + 1
end
close muCursor
deallocate muCursor
February 14, 2005 at 7:06 am
I guess your cursor is built under wrong syntax. I think you missed one 'fetch next' command. For more info see BOL
It's only my personal oppinion
February 14, 2005 at 7:55 am
Try declaring your cursor as static like
'declare muCursor cursor static for ...
It is likely the cursor is resetting when the table data changes from your update.
I should also add that you should explore the possibility of a set based solution that would perform better than the cursor.
HTH
February 14, 2005 at 10:23 am
I did not verified your total script but the basic thing missing is fetch system inside the loop
set @sql = 'declare muCursor cursor fast_forward for select sku, markup, id_cont from ItemPrice_Store' + isnull( @ConditionClause, '' )
exec (@sql)
set @rows = 0
open muCursor
while (0=0) begin
fetch next from muCursor into @sku, @markup, @id_cont
if @@fetch_status <> 0 break
if @markup is null continue
select @sql = 'update ItemPrice_Store set pluprice = ' + formula + ' where sku = ''' + @sku + ''' and id_cont = ' + ltrim(str(@id_cont)) from markup where markup = @markup
exec (@sql)
set @rows = @rows + 1
fetch next from muCursor into @sku, @markup, @id_cont
end
close muCursor
deallocate muCursor
Prasad Bhogadi
www.inforaise.com
February 14, 2005 at 10:36 am
?? I thought that the "fetch next" line right after the while loop begins is in the loop. But two posters have said the problem is with the fetch next? Can you clarify why the way the code is setup now is a problem?
I also thought that the fast_forward declaration created a static cursor, but now reviewing BOL it does not confirm. I will try adding the static keyword and let you guys know what happens. Thanks!
February 14, 2005 at 10:45 am
Both Prasad and Vidas are referring to a more common syntax where you do one fetch outside the loop, then another inside like.
FETCH NEXT INTO
WHILE @@FETCH_STATUS = 0
BEGIN
...
...
FETCH NEXT INTO
END
Your syntax should still work though.
February 14, 2005 at 10:56 am
More common, maybe, but does that necessarily mean it should be done that way? Why use two FETCH NEXT statements when you can easily use just one?
February 14, 2005 at 11:04 am
The scenario I've seen it used is when you don't want it to enter the loop if the initial fetch doesn't return anything (I failed to include an IF check in the sample). But you are correct. If it's not necessary to have two fetch statements then it doesn't make sense to code it that way.
February 14, 2005 at 11:12 am
Changing the curosr from fast_forward to static (they are mutually exclusive) resolved the issue!!! The client claims that it worked fine up until last week, but this seems to prove that it never would have worked.
I've always used the while loop with a single fetch next statement, as it makes more sense to me logically.
Thank you everyone for your help - this issue was really bugging me!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply