Потому, чо при определенных обстоятельствах, вместо создания курсора как временной таблицы иногда таблица источник просто переоткрывается в другой рабочей области с наложенным фильтром. По таким "отфильтрованным" таблицам недопустимо делать повторный запрос. Чтобы этого избежать надо давать опцию NOFILTER:

select * from aaa where name='M' into cursor zzz NOFILTER

select * from zzz where name='Mo' into cursor xxx

Подробнее читай здесь

http://]http://www.foxclub.ru/kb/index.php?sid=24056&aktion=artikel&rubrik=001&id=6&lang=ru

Раздел "Курсор"

Ссылка не получилась

http://www.foxclub.ru/kb/index.php?sid=24056&aktion=artikel&rubrik=001&id=6&lang=ru

Нет. Это одна из опций команды Select-SQL. Причем только в том случае, если запрос отправляется в курсор (INTO CURSOR)

А по ссылке сходить - религия не позволяет? Вот выдержка оттуда:

******************************************************************************
(...)

В зависимости от различных условий этот курсор может иметь разное физическое "воплощение" и разные свойства

Если SQL-запрос полностью оптимизируем, то вместо создания нового файла будет просто открыта та же самая таблица с наложенным на нее фильтром. Зачастую это очень неприятная неожиданность. Проверить, чем же физически является сформированный курсор, можно используя функцию DBF()



Если будет возвращено имя файла с расширением DBF, то данный курсор является той же самой исходной таблицей с наложенным на нее фильтром.

Если Вы хотите при любых запросах быть уверенными, что курсор - это именно временная таблица, а не исходная таблица с наложенным фильтром, то Вам следует добавить опцию NOFILTER



Эта опция появилась только в 5 версии Visual FoxPro, хотя там она еще не была документирована. В более ранних версиях необходимо добавлять фиктивные условия или признаки группировки, чтобы исключить возможность оптимизации.

Однако если курсор - это временная таблица, то это еще не значит, что эта временная таблица будет непременно физически расположена на диске. Вполне возможно, что вся временная таблица целиком поместится в оперативную память. Т.е. функция DBF('TmpTable') будет исправно показывать некий временный файл, но попытка найти его физически на диске окончится неудачей и функция FILE(DBF('TmpTable')) вернет .F.

Правда расположение временной таблицы целиком в памяти ни в коем случае не помешает работе с этой временной таблицей. Собственно, в подавляющем большинстве случаев Вас и не должно заботить где физически расположена та или иная таблица.

Если говроить конкретно о запросе

select * from aaa where name='M' into cursor zzz

то будет наложен фильтр, если существует индекс по полю name и этот индекс используется в rushmore-оптимизации данного запроса.

Переход на любую другую версию ничего не даст. Срособ работы один для всех.

Это зависит не от машины, а от уровня оптимизации запроса. Уровень оптимизации можно проверить, используя функцию SYS(3054).

В частности, на него влияюте еще такие факторы:

-) Текущая настройка SET DELETED
-) Если используется SET DELETED ON, то факт наличия индекса по выражению deleted()
-) Факт совпадения текущей настройки SET COLLATE и значение IDXCollate() индексов

Но по большому счету, трудно сказать, когда именно в результате выполнения запроса будет именно открыта та же таблица с наложенным фильтром. Это нигде не описывается подробно. Просто такое может быть. Тот факт, что это обычно происходит при полной оптимизации было установлено опытным путем. Но это вовсе не значит, что это единственное условие.

Поэтому, просто возьмите за правило, всегда, если Вы используете опцию INTO CURSOR, ставить дополнительную опцию NOFILTER.