分页符导致访问子报表性能下降
分页符导致访问子报表性能下降
提问于 2014-01-31 06:04:09
当子报表的子报表必须分页时，我的报表呈现的时间似乎要长3倍。
数据在何处中断的示例；
我有两个版本的此报告，其中一个细分劳动子报告的控件包含一条IIF语句，用于评估劳工注释字段是否为空。如果它不是空的，我插入Chr's作为return & newline，然后插入Labor注释本身。不包含此额外劳工注释的父报告的版本使子子报告足够小，可以放在一页上。
如果细分笔记足够长到第二页，就没有问题，报告从请求到交付PDF只需要2-4秒。当细分劳动子报告必须分到第二页时，至少需要20秒。
以及关于我如何通过编程来预测这个问题，或者完全回避它的建议？
回答 1
Stack Overflow用户
发布于 2014-02-04 03:29:22
找到原因了！这个问题是由报告的两个不同方面造成的，它们共同工作。
与我在问题中极其简单的Balsamiq模型相反，劳工子报告包含以下列；
当使用某些劳工代码时，
- Technician
- Start & stop times
- Hours
- Labor code
- Value from a lookup table。
子报告的两个方面，我已将其隔离为可能的原因；
- 为了计算第5列，对每条记录都执行了一次DLookup。当查找在同一行上时，也就是说，
=[LABORCODE] & " (" & DLookup(DisplayValue,LookupTable,[LABORCODE]) & ")".
- 使用IIF，在子报表的每一行上查找返回的值将在值本身之前加上
Chr(13) & Chr(10)。
(真的很差)解决方案的解释
我认为所发生的事情与DoCmd.OutputTo进程在决定如何处理之前多次尝试找出分页符将落在何处有关。通过删除DLookup并在源查询中添加作为连接所需的信息，我不仅更快地从查找表中获取了值，而且在3秒内将报告呈现和打印为PDF时，还向每行添加了条件CR/LF。Successkid.jpg。
这个故事的寓意是，你可能会看到一个问题，然后说，“我应该在这里使用DLookup”。现在，您有了#NAME?问题。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/21468386
复制相关文章
相似问题
腾讯云开发者
