ms-access - Access 报告不显示数据或失败并显示 "Multi-level GROUP BY cause not allowed in subquery."

Question

我有两个查询用于生成报告，问题是当我运行报告时，三个字段由于某种原因根本不显示任何数据。

查询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 和 % Spend。全部都没有数据。它不是 IIF 函数，因为我是否有这些函数或删除它们并不重要。

有什么想法吗？如果我直接连接到第一个记录集，它工作正常，但 SQL 会抛出错误消息:子查询中不允许使用多级 GROUP BY 原因。

有什么方法可以绕过该消息以直接链接到它，或者有人知道为什么这些字段会返回空白吗？我已经束手无策了!

Answer 1

今天我被同样的问题所困扰，我将在这里记录在我们的案例中解决该问题的步骤。关键是在构建排序和分组中使用的内部 GROUP BY 时，不要允许 Access 采用默认路由。

基本问题
您有一个报表 rptFoo，其 RecordSource 是查询 qryFoo。

您已经对 rptFoo 应用了一些排序和分组，这很好。但是 qryFoo 有点复杂；它包含一个子查询。

您将 qryFoo 微调到完美，调整并重新调整其子查询元素，一切看起来都很好，至少当您独立测试查询时是这样。当您启动报告并收到以下错误时，问题就开始了:

Multi-level GROUP BY clause is not allowed in a subquery

这是您提到的问题之一。

解决方案尝试 1:
如果你用谷歌搜索错误，你的第一个结果将是优秀的 Allen Browne site 。他在网站上有一个完整的部分，标题为 Surviving Subqueries 。对于这个特定问题，他的最佳建议是:

• 创建一个单独的查询来处理子查询。使用此查询 作为报告所基于的查询的源“表”。移动 子查询到较低级别的查询有时(并非总是)可以避免 问题，即使第二个查询很简单 从查询1中选择*；

因此，您创建了qryFooWrapper，其内容只是SELECT * FROM qryFoo。您将其设置为 rptFoo 的记录源，猜猜看，报告开始加载，没有错误。遗憾的是，它也只是显示一个空白字段，而不是原始子查询的结果。

这看起来就像您提到的最初问题，我们似乎陷入了死胡同。

解决方案尝试 2:
那么，把艾伦·布朗的建议放在一边，还有什么可以尝试的呢？那么有this discussion in Google Groups 。最初的建议看起来像是一个巨大的拼凑 - 将一个臭味的 UNION ALL 附加到您的初始查询中。这不可能是答案。

但是等等，线程中途出现了一些启发。 UNION ALL 所做的一切就是强制 Access 重组其生成的内部 GROUP BY 作为报告的一部分。在原始 qryFoo 中插入一个简单的 DISTINCT 将完成相同的工作，而且丑陋程度要低得多。

瞧，解决方案来了。 在原始查询中包含一个简单的 DISTINCT。。没有笨拙的UNION ALL，没有可怕的qryFooWrapper，也没有难闻的临时表。