Hi there,
I've just developed this big report in RS SQL 2000 that includes 6 subreports (repeated for each item in the database) and that should print some 800 pages. A light version of the report that only queries part of the data (about 10%, for testing purposes) run with success, including all subreports in about 15 minutes. Once I try to test the report with all the data (all subreports and the main report query directly from the cube in AS), it fails under three different scenarios:
1st: The timeout setting is left as the default 1800 seconds. After half an hour the report gets partially displayed and the subreports that were not processed within the 30 minutes period display only "The subreport data could not be displayed".
2nd: The timeout value is set not to time out. After about 2 hours, the report fails ("The page cannot be displayed"). I checked all log files and the only one I could identify as related to this was the following:
SQL Server Scheduled Job 'ReportScheduler_CreateJobs' (0x4A64EE6822172C478B4DBF1E385699D6) - Status: Failed - Invoked on: 2006-01-09 13:00:00 - Message: The job failed. The Job was invoked by Schedule 1 (DailyRun). The last step to run was step 1 (spc_sched_CreateJobs).
3rd: Tried to export the file to PDF instead of rendering as HTML. I got the message on the page "Action Cancelled" and an IE message box displaying a "Permission Denied" error.
I've tried many things and ran out of ideas. If anyone could give me any suggestions, I'd greatly appreciate it.
Thanks,
érico Maia
Are you generating these reports from a web-service?|||The reason I ask that question is that there is a very obscure 'Flag' that is set by default to ignore any new Timeout value set for the web service timeout. It is located on the generated class interface. I don't remember the exact name of this flag, but maybe this will help you in looking to solve this problem. If I can remember its name I will post on this board. Obviously, there is an issue with this solution, which is, any time you re-generate the web interface class you will have to reset this.|||
Hi,
The report is executed directly from the RS web interface. I'm trying now to generate it via a subscription, but also without success. After increasing the time out settings of all config files I know of, the report fails exactly at the 120 minutes mark.
Thanks,
érico
|||Hi érico
Did you manage to find a solution to your problem? I am experiencing exactly the same behaviour.
-- TINUS
|||I am having similar issues that I am trying to resolve as well, running 2KSP4 1042. It's a new issue for us, as all of our reports worked fine until I started composing some large combination reports which take a significant amount of runtime (an hour or better). Due to the complexities of one of the reports involved, batching it is difficult (though not impossible), but some of the reading I've done lends me to believe that it may not even fix the problem.The report attempts to execute, and the control indicates that it's processing, but eventually results in the "Page cannot be displayed" error, while the RS navigation tools still function normally. Furthermore, I can navigate to other reports and operate them, but if I navigate back to the report in question, the control immediately goes to the "Page cannot be displayed" message. I have to close and reopen IE for the control to attempt to start the report again.
I've seen this in one or two other rare circumstances before, and after reloading the browser, the report would render, but this is the first time I've consistently gotten this error message, and I have to think it's because of the lengthy runtime of the reports in question. One has 34 subreports in it (each of which has a runtime of 2-3 minutes), and the other is just a very in-depth query which (depending on parameters selected) could be run once or upwards of 60 times (with totaling at the end). I've disabled the RS timeout for the affected reports and it doesn't seem to help at all (I believe previously I was just getting rsProcessingAborted).
No comments:
Post a Comment