Как избежать двусмысленности здесь?

Question

Я на самом деле использую плохой дизайн с двумя курсорами (я знаю об этом, но тогда задача была проста, поэтому я не стал заниматься оптимизацией). Я использую запрос как этот:

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

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

Пока я действительно не нажал на кнопку Execute, я был уверен, что этот запрос неправильный и что он вылетит с ошибкой. Из того, что я вижу, используются два @@FETCH_STATUS. Таким образом, если только он не сохраняет состояние первого @@FETCH_STATUS где-нибудь в стеке перед открытием нового курсора, этот запрос не должен работать.

Может кто-нибудь сказать мне, как именно работает этот запрос? Мой главный вопрос о наличии нескольких проверок сравнения с @@FETCH_STATUS. Я вручную проверил некоторые результаты вручную, но не уверен, что это не удастся для углового случая, или запрос неверен, а SQL Server делает что-то еще.

Answer 1

@@ FETCH_STATUS всегда возвращает результат последней операции FETCH.

Answer 2

Запрос, как он есть, будет работать нормально.@@ FETCH_STATUS всегда возвращает статус последнего оператора выборки.Поскольку ваш @@ FETCH_STATUS следует сразу же за оператором FETCH, статус которого необходимо проверить, все будет в порядке.