Был написан проект под VFP80. Решил его просто перекинуть в VFP90 и пустить в работу, конечно некоторые запросы повели себя не так. Т.е. если запрос типа:
в VFP80 возвращал пустое множество (_Tally = 0), то в VFP90 запрос выдает одну запись ((_Tally = 1), но содержимое записи значение .NULL.. Конечно, поставив в начале стартового файла, выручает. И я работая в VFP60 с MSSQL7 заметил это же явление, ну видя это конечно обходил эти углы. Теперь видим, что это явление появилось и в VFP90. Видимо это стремление к однотипности получения результатов что в VFP, так и в MSSQL??? Но вместе с этим приходиться задумываться о получении пустого множества из запроса и его обработкой. Не все же пользоваться SET ENGINEBEHAVIOR. Ведь возможно появление более новой версии VFP. Приходится как бы переопределять себе в голове возможные результаты запросов. Какое мнение у Вас???

Urri...это скорее стремление приблизиться к стандарту ANSI SQL. Urri...Я думаю, в новой версии стало, наконец, так, как должно быть, правильно, и нужно потихоньку привыкать.Согласен!
Urri...в версиях 2.x просто не было null-ов, вот и приходилось возвращать пустой курсор, чтобы как-то отличить, были записи в выборке или нет. Потом-то null появился.Но .Null. появился начиная с VFP30, что же так долго переходили? Я конечно имею ввиду именно с пустым множеством.

ВладимирМ Запрос с GROUP BY выдает сообщение о синтаксической ошибке
SET ENGINEBEHAVIOR - это не стремление "к однотипности", а стремление к получению корректных результатов запроса. "Старый" режим работы может привести к неоднозначности (неопределенности) результата выборки.С этим я согласен, и что ошибка выдается при таких запросах это логично. Я начал говорить о пустом множестве. Где вроде как свыкся с получением именно пустого множества. А тут оказывается НЕТ. И к этому надо уже относиться по новому.

ВладимирМА почему не смущает разный результат запросов в младших версиях:

SELECT COUNT(*) FROM MyTab WHERE .F.
SELECT MAX(MyField) FROM MyTab WHERE .F.

В первом случае будет одна запись со значение 0, а во втором - ни одной записи. Почему собственно?

Так что, все логично. Т.е. как раз теперь все встало на свои места. Вне зависимости от используемых аггрегатных функций получаем одну запись.

Ну, а ее содержимое - это уже другой вопрос. Никто же не мешает написать так:

SELECT NVL(MAX(MyField),0) FROM MyTab WHERE .F.

Почему не исправили раньше? Это уже вопрос к команде разработчиков.Спасибо, согласен.