January 14, 2009 at 12:41 pm
I have a report deployed to RS2005. It works correctly. Now I have to make a change to the report. Before making the change, I tested the current project in VS2005. The report starts, but the little green wheel never stops turning and the report apparently 'hangs'.
Is there a way to step through the report to see where it stops? I don't want to deploy a change only to find that the new report does not work.
Thanks....
January 14, 2009 at 1:56 pm
You could do a couple of things... First, make sure that it's the same as the report on your reports server. You can do this a number of different ways, but the easiest is just load up both .rdl files in Source safe's show Differences tool and you'll be off.
also, check what SQL is being executed, you might try running that directly in SSMS or QA to test it. It sounds like it compiles, but it hangs as it's running, it could be that the default values for the parameters just run a HUGE query that never comes back... or at least doesn't come back within the timeout. Perhaps those parameter defaults were changed on the deployed version of your report.
Profiler or a server trace would help in the above circumstance as well.
January 14, 2009 at 11:24 pm
This is the original program that was deployed. There are several parts to it (subreports). I have executed the queries associated with each report and they return data in VS. I also went to the data tab and ran the stored procedure that gets the data used by these reports, both in VS and in SQL. It also works. I selected data that returned only 6 rows, and that took only a few seconds.
It looks like I have essentially done all the things you suggested, and I thank you for your diligence.
It would still be nice to be able to step through the 'program', like we can do in VS .NET code. I am totally stumped.
Any other thoughts, anyone??
January 15, 2009 at 6:17 am
Unfortunately in SSRS there is no real way of setting break points and such to step through the program... It's just a report... It should either compile or error, and it will either return data or not...
You could try turning off a few of the subreports (hiding them) though I'm not 100% sure that will actually not run the SQL associated with them, or you could actually delete and undo your delete of them...
Another thing that I've seen in my own environment that you might want to think about...
How many rows are you returning? I had a report, written by a previous developer of course, that was returning some 300,000 detail rows that the reporting server then agregated down to about 30 or so... The SQL code executed pretty quickly, but the report took forever to generate. The problem ended up being the time it took the server to pass the 300,000 rows from my SQL Server across the network to the Report Server. I ended up moving the aggregate logic to the SQL code and since it was now only passing about 30 rows, the report generated much more quickly.
If your SQL Database and your report server are on the same physical machine there really shouldn't be anything in the way of network latency, however, if you development machine is on a slower network(100 instead of 1 GB) or a different subnet or some other such network separation you may be seeing that as an issue if you are passing a lot of data from your query to your machine...
-Luke.
January 18, 2012 at 7:17 am
I have found many times when a report never seems to finish that the first thing to check is the Report Parameters. I have had occasions where they have gotten wiped out and experienced the same problem you are having
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply