Много разных вкусностей содержит в себе VFP8, по сравнению с предыдущими версиями. Взять хотябы конструкцию INSERT…SELECT… И все-же:
- может я чего-то не понял, но в HELPе VFP8 указано, что в SQL-запросе, в разделе GROUP BY, должны перечисляться ВСЕ извлекаемые поля, указанные в разделе SELECT…FROM, кроме агрегированных и memo-полей (а иначе - даже SQL-дизайнер бессилен, проверено). В качестве примера:

исходная таблица - table1 (field1 n(8), field2 c(50), field3 n(3), field4 m(4)),
запрос – SELECT field2, field3, field4 FROM table1 GROUP BY 1,2 INTO TABLE table2,
(надо получить таблицу table2 с уникальными комбинациями полей field2 и field3, содержащую также и memo-поле field4, содержимое которого на данном этапе не важно (ибо оно одинаковое, хотя и непустое), но важна именно такая структура выходного файла, а при дальнейшей обработке файла table2 информация из этого поля будет задействована)

Так вот, в VFP6 и VFP7 такой запрос срабатывает за милую душу, а вот VFP8 – требует перечисления всех SELECT-полей запроса в разделе GROUP BY… Это что же – переделывать все 48 страниц программного кода? Кроме того, на мой взгляд, такое нововведение серьезно ограничивает гибкость SQL-запросов в VFP8, хотя должно быть наоборот – усовершенствование от версии к версии. Выходит, как писал дедушка Ленин – «шаг вперед – два шага назад»? Или я чего-то недопонял…

To Андрей Давыдов :
Спасибо, поставлю обратно VFP8 - посмотрю. Но я, ведь, именно в разделе ENGINEBEHAVIOR и вычитал то, о чем написал... Ладно, может, невнимательно смотрел, попробую еще раз.

2 Андрей Давыдов:
Стандарт-то стандартом, но тогда на кого расчитана такая стандартизация? Если на нормально подготовленных программеров, то они и так не допустят таких оплошностей, от которых страхует ENGINEBEHAVIOR(80) по сравнению с ENGINEBEHAVIOR(70). А если на начинающих, то почему тогда SQL-designer в VFP8 не указывает на ошибку КОНКРЕТНО, не говоря уж о том, что, имхо, он должен ее в таком случае вообще нейтрализовать…