September 25, 2003 at 3:58 pm
I'm developing a complex T-SQL procedure which uses nested cursors; or at least tries. Using the debugger it appears that @@FETCH_STATUS = 0 for the first cursor and reads the first row; then the nested cursor runs and reads all the rows. When the nested cursor is complete @@FETCH_STATUS becomes -1 which is the value when it tries to read the second row of the unnested cursor. Can nested cursor be run or would it be necessary to build a second procedure which is executed from within the first? Any recommendations would be appreciated.
Steve King
September 25, 2003 at 4:18 pm
I am aware that @@FETCH_STATUS is a global variable, after a while using BOL, and when the nested cursor updates @@FETCH_STATUS to -1 the unnested cursor sadly claims it as it's own. My real question is how do I implement a design that will work?
September 25, 2003 at 5:14 pm
When using nested cursors, you end up being dependent on when you read your cursor in the loop. For example:
declare c_1 CURSOR FOR
SELECT Field1 From Tbl1
Declare @F1 int
Declare @F2 varchar(20)
Open c_1
FETCH NEXT FROM c_1 INTO @F1
WHILE @@FETCH_STATUS = 0
BEGIN
Declare c_2 CURSOR FOR
Select TxtFld From Table2
WHERE txtID = @F1
OPEN c_2
FETCH NEXT FROM c_2 INTO @F2
WHILE @@FETCH_STATUS = 0
BEGIN
Print @F2
FETCH NEXT FROM c_2 INTO @F2
END
-- At this point, @@FETCH_STATUS <> 0
CLOSE c_2
DEALLOCATE c_2
FETCH NEXT FROM c_1 INTO @F1
-- at this point, @@FETCH_STATUS = 0 if new data was fetched
END
CLOSE c_1
DEALLOCATE c_1
So, if you code your loops with the read at the top of the loop (as I have seen some folk do), then the @@FETCH_STATUS value is retained from the inner loop, and the outer loop exits, even though the outer loop is not complete. However, if you code it as above (a 'priming read' before the loop, and additional reads at the end of the loop) then the @@FETCH_STATUS is correct for the given loop whenever it is checked.
September 25, 2003 at 6:23 pm
Assign the value of @@FETCH_STATUS to a local variable and use that in your logic
eg:
FETCH NEXT FROM Outer blah...blah...
SET @Outer_loop = @@FETCH_STATUS
WHILE @Outer_loop = 0
BEGIN
FETCH NEXT FROM Inner blah...blah...
Set @inner_loop = @@FETCH_STATUS
WHILE @Inner_loop = 0
BEGIN
do some stuff
FETCH NEXT FROM inner blah...blah...
Set @inner_loop = @@FETCH_STATUS
END
FETCH NEXT FROM Outer blah...blah...
SET @Outer_loop = @@FETCH_STATUS
END
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
Edited by - phillcart on 09/25/2003 6:24:05 PM
--------------------
Colt 45 - the original point and click interface
September 29, 2003 at 5:51 pm
Thanks! You recommendations helped me overcome this issue. I wasn't using a priming fetch. Now it works great. Documentation was really spotty and didn't explain the need for it. Having used Recordsets in Visual Basic I was unprepared for this.
Steve King
January 12, 2023 at 7:16 am
This was removed by the editor as SPAM
January 12, 2023 at 7:19 am
This was removed by the editor as SPAM
January 12, 2023 at 8:03 am
This was removed by the editor as SPAM
February 9, 2023 at 2:42 pm
This was removed by the editor as SPAM
February 9, 2023 at 3:00 pm
Ok... since SPAM keeps necroing this 2 decade old thread and someone might read it and without knowing what the cursors are actually being used for, I'll just up and say that using Nested Cursors or even Single Cursors is usually the worst way possible to do anything except for "flow control" and even that might be able to be repaired by fixing the stuff in the flow.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 9, 2023 at 3:06 pm
And, wow... Phil Carter. Were did you ever get off to?
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply