【发布时间】:2009-03-30 10:01:48
【问题描述】:
报表设计、生成和维护并不难,但很乏味。我们在 Crystal Reports XI 中有许多旧版(不同程度的旧版)报表。这些是为 A4/PDF 设计的 - 不一定是印刷的,但具有可预测的布局,我们不可能很快淘汰它们。
所有都连接到现有的存储过程 (SQL Server 2005) 以获取它们的数据。花了很多时间让这些报告看起来就这样。报告的实际创建主要通过 .NET/C# API 完成并导出为 PDF。有许多本地开发和维护的应用程序是稳定的并且可以很好地处理这个过程。
因此,我们喜欢 Crystal Reports 稳定、我们的应用程序可靠地生成这些报告、PDF 输出一致以及当 Crystal Reports 模板获得批准和设置后,它就可以正常工作的事实。
但这种情况存在一些大问题。最大的问题是对底层报告模板本身的任何更改都是一个巨大的痛苦。使 Crystal Reports 模板达到用户满意的程度是一件非常麻烦的事情,并且可能涉及 DTP/图形/数据库/协调和无数其他小问题的长期迭代。
再加上 Crystal Reports 是一种相对稀有的技能,而且没有人愿意承认,我们正试图想出替代解决方案。
我已经开始考虑一些想法 - 欢迎任何其他想法!
- Crystal Reports 2008 与 XI 相比有什么好处吗?
- 其他人是如何管理从 CR 迁移出来的?又该做什么?
- 鉴于数据访问层结构良好,是否可以通过 Excel 服务生成图形,然后将它们作为图形导入框架模板?水晶,另一个 - 有没有人尝试过这样的事情?
- Reporting Services 是否更好? (我们有一些 RS 技能,但同样,人们不愿意真正承认知道任何事情的另一件事。)
- 是否有任何可用的布局工具(最好使用 .NET API)用于在过去称为桌面出版的内容?如果我们有图形/表格/其他对象作为可以自动渲染的图像,
理想情况下,我希望转向一种解决方案,让用户可以更好地控制底层更改,以及是否可以在我们可以提供给他们的工具内以编程方式处理这件事,这样我就可以编码而不是编辑 Crystal Reports模板。
【问题讨论】:
标签: layout crystal-reports reporting graphing