大型报告实施建议 250 - 300 页
我的小组有一份最近使用 Reporting Services 2005 和 NeoDynamics 条形码组件开发的报告。 该报告用于退货授权，由 2 个主要报告组成。
报告中的第一组数据是 授权表，列出所有 行项目产品和一些标题 信息（将其视为 发票）。
报告的第二项是所有产品的列表 每页打印 4 个产品。 每个产品有 3 个条形码和 1 个 徽标。
退货授权平均只需几秒钟即可生成，并以 PDF 形式传输给用户。 平均文档长度约为 6 - 8 页。 我们还有一些退货授权（不幸的是），最多可达 300 页左右（不到 10% 的授权超过 15 页）。 在尝试将报告合并为 PDF 几分钟后，Reporting Services 似乎超时。
我的问题是，将此报告转换为 PDF 格式的最佳选择是什么？ 我们的用户可以每周 7 天、每天 24 小时生成报告，并以 PDF 格式传输给他们。 我们可以采取哪些措施来提高报告服务绩效？
My group has a report that was recently developed utilizing Reporting Services 2005 with the NeoDynamics Bar Code component. The report is for return authorizations and consists of 2 main reports.
The first set of data on the report is
the authorization form, listing all of
the line item products and some header
information (think of it as an
invoice).The second item on the report is the listing of all of the products
which prints out 4 products per page.
Each product has 3 bar codes and 1
logo.
The average return authorization is produced in just a couple of seconds and streamed to the user as a PDF. The average document is about 6 - 8 pages in length. We also have some return authorizations (unfortunately) that can get up to about 300 pages (less than 10% of authorizations are more than 15 pages). Reporting Services seems to timeout after minutes of trying to put the report together as a PDF.
My question is, what is our best option for getting this report into a PDF format? Our users are allowed to generate the report 24x7 and it is streamed to them as a PDF. Are there things we can do to improve the reporting services performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我对 Reporting Services 不是特别熟悉。 我认为这是微软的产品。 这意味着您可能正在与后端的 SQL Server 数据库进行通信。 所以有两条建议。
(2) 无论如何都是一个好主意......它将防止锁升级和相关的不良情况。
I'm not particularly familiar with Reporting Services. I think it's a Microsoft product. Which means that you're probably talking to a SQL Server database on the back end. And so there are two pieces of advice.
(2) is a good idea anyway... it will prevent lock escalation and related badness.