Crystal Reports：5 个顶级性能测试

你的杰作报告已经完成。它不仅满足了客户的期望，而且超出了他们的预期，他们想要的只是以多种方式进行精美地总结和展示。然后…灾难！你尝试针对实时数据库运行一个月的报告，而不是用于开发的为期两天的测试数据。突然，你的报告的运行时间从二十秒增加到两个小时。每个 Crystal Reports 开发人员都经历过这种情况，这可能是报告设计中最令人沮丧的方面之一。值得庆幸的是，有很多方法可以用来对抗糟糕的性能，其中任何一种方法都可以带来巨大的好处。以下是导致性能不佳的五个最可能的原因以及如何减轻其影响。 1. 数据库设置。 这可能在你的直接控制范围之内或之外进行更改，但数据库并非理想地设置。两个主要因素是： a. 你正在过滤的字段未被索引。你可以通过参考“数据库专家”窗口中的“链接”选项卡来检查是否是这种情况。已索引的字段旁边有彩色标记。我个人见过由于将索引添加到重要（到报告过滤器）字段中，报告的运行速度提高了数百倍。 b. 使用视图而不是表进行报告可能会对报告的性能造成毁灭性的影响。这主要是因为视图没有索引。视图是表的集合（就像基本报告一样），通常用于简化最终用户的数据。避免这种情况的唯一方法是报告组成视图的表。通过“数据库专家”可以确定字段的来源是表还是视图，因为表和视图是分开列出的。确定哪些表构成一个视图可能要复杂得多，你可能需要数据库文档的帮助。此外，在使用 Oracle 数据库时，关闭查询的大小写敏感选项可以真正加快报告时间，但可能需要重写现有报告。 2. 使用错误的 ODBC 驱动程序。 ODBC 驱动程序是 Crystal Reports 连接到数据库的方式。通常有各种各样的 ODBC 驱动程序可以用于任何特定品牌的数据库，而且有些比其他的好。真正测试这一点的唯一方法是使用所有合适的 ODBC 驱动程序运行报告，看看哪个最有效。经验告诉我，与数据库关联的软件提供的 ODBC 驱动程序通常是最佳选择。 3. 过度使用子报告 每个子报告就像另一个访问数据库的报告，如果将该子报告放置在“详细信息”部分中，它将为主报告加载的每个记录运行。即使放置在“组”部分中，子报告仍将运行多次。报告部分通常是放置子报告的理想位置，因为它们只会运行一次。但这仍然将一个报告变成两个，就性能而言。消除子报告引起的性能问题的最佳方法是不使用它们。百分之九十九的子报告是不必要的，并且可以使用其他方法（通过分组、运行总数和/或公式）获得相同的结果。 4. 表链接 除等于（'='）的链接类型以外的任何内容都会导致性能的大幅下降。 “链接选项”窗口（通过右键单击特定链接访问）将允许重置任何值。如果需要这种链接，可以通过“组选择”或通过格式化（并隐藏不需要的记录）在将它们加载到报告中后获得相同的结果。 5. 记录选择 当记录选择的代码编写正确时，Crystal Reports 会将所有逻辑传递给数据库作为 SQL，并且仅返回所需的数据。如果记录选择不是以 SQL 友好的方式编写的，Crystal Reports 将取回所有数据，然后对其进行本地过滤。这可能比在数据库上计算时慢得多。使用“记录选择器专家”将保证创建的任何过滤器都将在数据库上进行评估并尽可能高效。另外一点，在某些情况下可能会有所作为，即报告计划运行时。繁重的网络流量或数据库使用情况可能会影响报告的运行时间。通过上述几点工作将提高运行缓慢的报告的效率。从一开始就考虑到所有这些来构建你的报告，以后将为你节省重新开发时间。