Мучившись сегодня тем, что, по моему мнению, является той же проблемой, я запишу здесь шаги, которые решили ее в нашем случае. Ключ не должен позволять Access использовать свой маршрут по умолчанию при структурировании внутренней GROUP BY, используемой в Sorting And Grouping.
Основная проблема
У вас есть отчет rptFoo
, чьим источником записи является запрос qryFoo
.
Вы применили сортировку и группировку к rptFoo
, и это нормально. Но qryFoo
немного сложен; он содержит подзапрос.
Вы дорабатываете qryFoo
до совершенства, настраиваете и подстраиваете его элемент подзапроса, и все это выглядит хорошо, по крайней мере, когда вы тестируете отдельный запрос. Проблемы начинаются, когда вы запускаете отчет и получаете эту ошибку:
Многоуровневое предложение GROUP BY не допускается в подзапросе
Это одна из проблем, которую вы упоминаете.
Попытка разрешения 1:
Ваш первый результат, если вы погуглите ошибку, будет отличным сайтом Аллена Брауна . У него есть целый раздел на сайте под названием Surviving Subqueries . Лучшее из его предложений по этой конкретной проблеме таково:
- Создайте отдельный запрос, который обрабатывает подзапрос. Используйте этот запрос
в качестве исходной «таблицы» для запроса основан отчет. Перемещение
подзапрос к запросу более низкого уровня иногда (не всегда) избегает
проблема, даже если второй запрос так же прост, как
SELECT * FROM Query1;
Итак, вы создаете qryFooWrapper
, содержимое которого просто SELECT * FROM qryFoo
. Вы делаете это источником записи для rptFoo
и, угадайте что, отчет начинает загружаться без ошибок. К сожалению, это также просто показывает пустое поле вместо результатов вашего исходного подзапроса.
Это похоже на начальную проблему, о которой вы упомянули, и мы, похоже, зашли в тупик.
Попытка разрешения 2:
Итак, оставляя предложения Аллена Брауна одной стороне, что еще можно попробовать? Ну, есть это обсуждение в группах Google . Первоначальное предложение похоже на гигантский клудж - добавьте вонючий UNION ALL к своему первоначальному запросу. Этот не может быть ответом.
Но подождите, на полпути внизу появляется какое-то освещение. Все, что UNION ALL делает, - это заставляет Access реструктурировать внутреннюю GROUP BY, которую он создает как часть вашего отчета. И вставка простого DISTINCT в исходный qryFoo
сделает то же самое, с гораздо меньшим уродством.
И, вуаля, решение. включает простой DISTINCT в исходный запрос. . Никаких глупостей UNION ALL
, никаких ужасных qryFooWrapper
и никаких вонючих временных столиков.