我有两个查询用于生成报告,问题是当我运行报告时,三个字段由于某种原因根本不显示任何数据。
查询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。
有没有办法绕过该消息直接链接到它或有没有人知道为什么这些字段会回来空白?我在这里斗智斗勇!
答案 0 :(得分:3)
今天被我认为是同样的问题折磨了,我将在这里记录在我们的案例中解决它的步骤。关键是在构造排序和分组中使用的内部GROUP BY时,不允许Access采用其默认路由。
基本问题
您有一个报告rptFoo
,其RecordSource是查询qryFoo
。
您已对rptFoo
应用了一些排序和分组,这很好。但qryFoo
有点复杂;它包含一个子查询。
你微调qryFoo
完美,调整并重新调整它的子查询元素,它看起来都很好,至少在你独立测试查询时。当您启动报告并出现此错误时,问题就会出现:
子查询中不允许使用多级GROUP BY子句
这是你提到的问题之一。
决议尝试1:
如果你谷歌错误,你的第一个结果将是优秀的Allen Browne site。他在网站上标题为Surviving Subqueries的整个部分。对于这个特定问题他的建议的最好看是这样的:
因此,您创建的内容仅为qryFooWrapper
的{{1}}。你把它作为SELECT * FROM qryFoo
的记录源,猜猜看,报告开始加载没有错误。可悲的是,它只是显示一个空白字段而不是原始子查询的结果。
这看起来像你提到的最初问题,我们似乎处于死胡同。
决议尝试2:
所以将Allen Browne的建议留在一边,还有什么可以尝试的?那就是this discussion in Google Groups。最初的建议看起来像一个巨大的kludge - 在您的初始查询中添加一个臭臭的UNION ALL。 无法成为答案。
但等等,在线程的一半处有一些照明。所有UNION ALL正在做的是强制Access重新构建它作为报告的一部分生成的内部GROUP BY。在原始rptFoo
中插入一个简单的DISTINCT也可以完成同样的工作,而且不那么丑陋。
而且,呃,一个解决方案。 在原始查询中包含一个简单的DISTINCT。 。没有kludgy qryFoo
,没有可怕的UNION ALL
,没有臭的临时桌子。