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语句的状态。由于你的@@ FETCH_STATUS紧跟在要检查其状态的FETCH语句之后，你会没事的。

如何在这里避免歧义？

2 个答案: