在分页符上访问子报表性能降级

Question

当子报表的子报表必须分页时，我的报告似乎需要花费3倍的时间。

数据中断的示例;

我有两个版本的报告，其中一个Segment Labor Subreport的控件包含一个IIF语句，用于评估人工评论字段是否为空。如果它不是空的，我插入Chr's用于返回＆amp;换行，然后是劳工评论本身。不包含此额外人工注释的父报告版本使子报告小到足以适合一页。

如果细分注释足够长，可以进入第二页，则没有问题，报告距离被要求提供PDF只有2-4秒。当Segment Labor子报告必须分解到第二页时，它的最小值为20秒。

关于我如何以编程方式预测此问题或者完全支持这一问题的建议？

Answer 1

找到原因！这个问题是由报告的两个不同方面共同造成的。

与我在问题中非常简单的Balsamiq模型相反，Labor子报告包含以下列;

1. 的技术员
2. 开始＆amp; 停止次
3. 小时
4. 人工代码
5. 使用某些人工代码时来自查询表的值。

我作为可能原因隔离的子报告的两个方面;

1. 为了计算第5列，每个记录都执行了一个DLookup。当查找位于同一行时，这个工作正常，即

   =[LABORCODE] & " (" & DLookup(DisplayValue,LookupTable,[LABORCODE]) & ")"。

2. 使用IIF，从子报表的每一行查找返回的值将在值本身之前加Chr(13) & Chr(10)。

---

（非常差）解决方案说明

我认为发生的事情与DoCmd.OutputTo进程有关，试图在决定做什么之前弄清楚分页符会多少次掉落。通过删除DLookup并在源查询中添加我需要的信息作为JOIN，我不仅更快地从查找表中获取值，而且在将报表呈现并打印到PDF时向每行添加了条件CR / LF在3秒内。 Successkid.jpg。

故事的道德是你可能会看一个问题然后说：“我应该在这里使用DLookup”。现在您遇到了#NAME?个问题。