Question

I am actually using a bad design with two cursors (I am aware of it but then the task was simple so I did not bother with the optimization). I am using a query like this:

DECLARE cursor1 CURSOR FAST_FORWARD FOR
SELECT DISTINCT name FROM #NameMeta;

OPEN cursor1;

FETCH NEXT FROM cursor1 INTO @name

WHILE @@FETCH_STATUS = 0
BEGIN

  DECLARE cursor2 CURSOR FAST_FORWARD FOR
  SELECT DISTINCT place FROM #PlaceMeta;

  OPEN cursor2;

  FETCH NEXT FROM cursor2 INTO @place

  WHILE @@FETCH_STATUS = 0
  BEGIN

  ...
  ...
...
...

Until I actually clicked on the Execute button, I was pretty sure that this query is wrong and that it will bail out with an error. From what I see, there are two @@FETCH_STATUSs being used. So unless it is saving the status of the first @@FETCH_STATUS somewhere on a stack before opening a new cursor, this query should not work.

Can someone tell me how exactly this query works? My main question is about having multiple comparison checks with @@FETCH_STATUS. I manually hand verified some of the results but am not sure if this will fail for a corner case or the query is infact right and SQL Server is doing something else.

Answer 1

@@FETCH_STATUS always returns the result from the most recent FETCH operation.