Studio 2008 SP1 BIDS crashes whenever it tries to render a large report. It does not matter if the report was created with the wizard or manually. It does not matter if it a stored procedure or just SQL. We have several developers in our shop and we have all experienced the same problem. We have to limit the result set with something like "SELECT TOP 1000 ..." while we are developing and then remove the limit or filter when we deploy. After it is deployed there is no problem with the reporting engine rendering the html. The problem is only in Visual Studio 2008 BIDS. When it tries to render a large report it crashes. I think probably because it not rendering html but attempting to draw a representation of the report in the client area of the window. We would like to see a better solution. Any ideas?

Hi dare, Use the system performance monitor to trace the memory used when using BIDS. Maybe you should add more hardware to support it. If you want better suggestions, you can put your question in visual studio forum. thanks, Jerry

Hi Jerry, Thanks for your reply. Trust me, it is not a hardware problem. It is definitely a Visual Studio 2008 issue. Like I said, we have a large and very talented group of developers. More than one of us have very diverse backgrounds ranging all the down through assembly programming. We work with very large databases, some with hundreds of millions of records for a single year of data. Some of our reports consist of 50+ columns with up to a hundred thousand rows. Reporting Services can render the reports once deployed to the server. But Visual Studio 2008 cannot render reports that large. Visual studio 2005 could do it but it would take a few minutes. VS2008 does not handle the rendering as well and obviously runs out of resources and then just crashes without a warning. I could give you other symptoms that are most likely related. Such as when ever a report has, lets say more than 20 columns, the scrolling in VS2008 gets very sluggish. I think I am going to have one of our architects open a premier support issue with Microsoft to see if they can come up with a fix for it. After all they did not come out with BIDS development in VS2010 so they need to provide support for issues in VS2008 BIDS. Anyway thanks for you reply. Cheers Tom... Tom...

I can confirm that we are also seeing these problems also, namely that BIDS 2008 crahses when you have a lot of rows being returned to the reprot. Scrolling either horizontally or vertically is also extremely sluggish. The same report runs fine with BIDS 2005 so we are uninstalling and regressing back to that. 3 developers all get the same problems: Version 9.0 30729.1 SP Running on XP 5.1 SP3 Is anyone aware of a fix for this?

I am getting this also, along with other members of my team and we all are running the current VS 2008 sp's as well as the latest sp2/CU updates for SQL server 2008 R1... This is really getting annoying with VS 2008...

We noticed that a long-running (5 minute processing time) stored procedure caused 3x the amount of rendering time in the report when run on the server, and wouldn't come back at all running from Visual Studio. Laptop has 4gb RAM, 32-bit Windows 7 running SQL Server developer with all services. The report displayed 4 graphs and a 50 row chart. Not a lot of actual data was returned from the proc, but it operated on a 19 million row table with no indexes. Optimizing the stored proc plan by adding indexes to the tables helped decrease the rendering time of the report, oddly enough. Not sure why processing time affects rendering time... probably something to do with the graphs. I'm also seeing slowness scrolling with larger reports in design mode, probably due to the way the WPF control renders. It's a quad core HP with 8gb ram, an NVidia graphics card. Something is coded very inefficiently with the report designer to cause this. After deploying to the server, which was on the same developer laptop, the report could also run in unoptimized mode and returned data. The unoptimized proc actually hung SQL 2008 query analyzer for awhile before returning data. So perhaps in our case it was the underlying data layer causing the performance issue. Our fixes were: Add a hidden row limiter parameter that gets changed at deployment time so development could continue. Fix the design of the query and the query plan and the underlying indexes to improve performance. Doesn't fix the underlying design-time issues with the designer though. Cheers, Andrew Andrew Sears, T4G Limited, http://www.performancepointing.com