Отчет о доступе либо не отображает данные, либо содержит ошибку «Многоуровневая причина GROUP BY не разрешена в подзапросе». - PullRequest
2 голосов
/ 11 мая 2010

У меня есть два запроса, по которым я генерирую отчет, проблема в том, что когда я запускаю отчет, в трех полях по какой-то причине вообще не отображаются данные.

Запрос 1:

SELECT ClientSummary.Field3 AS PM, 
       ClientSummary.[Client Nickname 2] AS [Project #], 
       ClientSummary.[Client Nickname 1] AS Customer, 
       ClientSummary.[In Reference To] AS [Job Name], 
       ClientSummary.Field10 AS Contract,

      (select sum([Billable Slip Value]) 
       from Util_bydate as U1 
       where U1.[Client Nickname 2] = ClientSummary.[Client Nickname 2]) 
          AS [This Week],

      (select sum([Billable Slip Value]) 
       from Util as U2 
       where U2.[Client Nickname 2] = ClientSummary.[Client Nickname 2] ) 
          AS [To Date],

      [To Date]/[Contract] AS [% Spent],

      0 AS Backlog, 

      ClientSummary.[Total Slip Fees & Costs] AS Billed, 
      ClientSummary.Payments AS Paid, ClientSummary.[Total A/R] AS Receivable, 

      [Forms]![ReportMenu]![StartDate] AS [Start Date], 
      [Forms]![ReportMenu]![EndDate] AS [End Date]

FROM ClientSummary;

Запрос 2:

SELECT JobManagement_Summary.pm, 
       JobManagement_Summary.[project #], 
       JobManagement_Summary.Customer, 
       JobManagement_Summary.[Job Name], 
       JobManagement_Summary.Contract, 
       IIf(IsNull([This Week]),0,[This Week]) AS [N_This Week], 
       IIf(IsNull([To Date]),0,[To Date]) AS [N_To Date], [% Spent], 
       JobManagement_Summary.Backlog, 
       JobManagement_Summary.Billed, 
       JobManagement_Summary.Paid, 
       JobManagement_Summary.Receivable, 
       JobManagement_Summary.[Start Date], 
       JobManagement_Summary.[End Date]
FROM JobManagement_Summary;

Когда я запускаю отчет из запроса 2, эти 3 поля не отображаются. N_This Week, N_To Date и% Spent. У всех нет данных. Это не функции IIF, так как не важно, есть ли они там или я их удалю.

Есть мысли? Если я подключаюсь напрямую к первому набору записей, он работает нормально, но затем SQL выдает сообщение об ошибке: Многоуровневая причина GROUP BY не разрешена в подзапросе.

Можно ли как-то обойти это сообщение, чтобы связать его напрямую, или у кого-нибудь есть ЛЮБАЯ подсказка, почему эти поля возвращаются пустыми? Я в конце концов здесь!

1 Ответ

3 голосов
/ 12 августа 2011

Мучившись сегодня тем, что, по моему мнению, является той же проблемой, я запишу здесь шаги, которые решили ее в нашем случае. Ключ не должен позволять 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 и никаких вонючих временных столиков.

...