Yes, it is totally possible to publish a SSRS report into your PowerPivot Gallery – In fact, the gallery invites you to do so with the “New Report Builder Report” item in the PowerPivot gallery’s silverlight application.

But as my buddy George Orwell might say, “All reports are equal, but some reports are more equal than others.”

Essentially, you’re not going to get a snapshot generated for your SSRS reports stored here.

The status message displayed can be somewhat confusing, too: “Snapshots were disabled to protect sensitive content” is dead on the money, but infers there might be a way to enable this sensitive content. Don’t waste your time looking for the magic property to enable dynamic SSRS snapshots, however. No such animal.

The “Snapshots were disabled” message is used in a number of situations where connections in a xlsx published to the gallery aren’t quite right, and I guess we chose to lump the SSRS scenario in with them.

Last week I was in a bit of a panic when Excel Services and SQL Reporting Services (MOSS Integrated) broke on nearly all of my “demo” Hyper-V images.

I could publish to Excel Services, but attempting to render caused this exception to get thrown:

ProcessWebException: A Web exception during ExecuteWebMethod has occurred for server: http://atlasone:56737/SharedServices1/ExcelCalculationServer/ExcelService.asmx, method: OpenWorkbook, ex: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

All of these machines had worked flawlessly before, so I was flummoxed.

In addition, when I tried to render any SSRS MOSS Integrated reports…no joy:

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

Interestingly enough, if I manually browsed to http://server/reportserver, I could run reports with no problems…just no luck via MOSS

I also noticed that all of the RSS feeds on my MOSS site had stopped working.

After doing a bit of back-tracking, I saw that all of these boxes had one thing in common: Windows Update had attempted to install security hotfix KB967723, and for reasons unknown, the process had failed. If there was no initial attempt to install KB967723, I had no problems…if WU tried to install it, my image was hosed.

Happy endings: By manually downloading and installing the hotfix and then bouncing the machine, all the broken stuff started functioning correctly. (The hotfix just happens to be network-related in nature, go figure)

Posting this in the hopes I can give someone back an afternoon of their lives!

If you’ve been waiting for the Click Once version of Report Builder 2.0, your wait is over (as long as you don’t mind using non-RTM bits).

The SP1 CTP will allow you to launch RB 1.0 or 2.0 as Click Once applications in both Native and MOSS integrated mode.

Have at it!

http://www.microsoft.com/downloads/details.aspx?FamilyID=6f26fc45-f0ca-49cf-a6ee-840c7e8bb8af&displaylang=en

Oh, and how to do you turn it on? In native mode, go to Site Settings,  then set Custom Report Builder launch URL to /ReportBuilder/ReportBuilder_2_0_0_0.application. MOSS integrated mode has a similar property which can be found in the Set Server Defaults link of the Reporting Services section of the Application Management inside the SPS Central Administration console.

SQL Server 2008 Cumulative Update 1 was released a few weeks ago, and contains a very nice (but not promoted) improvement around PDF rendering.

For those who regularly render reports which require specific fonts and character sets (for example, trying to render a “simple Chinese” language report to PDF), you need to have the font in question installed on client where you read the exported PDF or you see garbage. Our PDF rendering extension didn’t include “font embedding” in 2000/2005/2008 RTM, which something that the Acrobat format does support.

Well, in CU1, we added font embedding to the PDF extension – multilingual reports just got a little bit easier!

Late last week I stumbled into a really informative conversation around how 2005 reports are “automagically” upgraded to 2008. Thought I’d post the broad strokes here in FAQ format for everyone’s use. Thanks to Robert Bruckner who contributed most of the information! 

Q: If I upgrade my instance of SSRS 2005 to 2008, what happens to the reports in reportserver database? Do they get automatically upgraded? 

A: Reports in the catalog are automatically upgraded from 2005 to 2008 when they are first run on the newly upgraded machine. Each report is upgraded only once, not each time it is run.  

Q: If my report gets automatically upgraded to the 2008 schema, can I get my original 2005 report back somehow?  

A: Yes, you can. The upgrade process does not actually delete the original 2005 report, but simply makes a copy of it and stores the compiled result. If you “Edit” the report using Report Manager (to download a copy of the RDL) or call GetReportDefinition(), the original 2005 report definition will be returned. 

Q: What if the report doesn’t get upgraded for some reason – will it still run on 2008? 

A: SQL Server Reporting Services 2008 has the ability to render reports using the new “on demand” engine, and the older 2005 engine. 

Q: So, if my 2005 report gets automatically upgraded to the 2008 RDL schema, is there any way I can get the upgraded version (2008) out of the server for use elsewhere? 

A: No. You’ll need to use BIDS or Report Builder (v2) to upgrade your 2005 report to the 2008 schema. 

Q: I know that every once in a while, a 2005 report won’t auto-upgrade to 2008 successfully. How can I tell if a report I’m running is being rendered in 2005 or 2008 mode? 

A: We attempt to upgrade a 2005 report to 2008 once and only once. If the process fails the first time, we don’t try again. To see which engine is being used to render a report, use the new ExecutionLog2 view in the reportserver database, examine the AdditionalInfo column and check the <ProcessingEngine> element. A value of 2 indicates the new 2008 “on demand” rendering engine was used, while a value of 1 means the older, 2005 engine was used.

With the RTM of SQL 2008, it looks like a slightly older version of the add-in has been removed from microsoft.com. Unfortunately, all of the search engines (including Live) are pointing at the old, dead page.

If you search for the add-in directly from Microsoft.com, you’ll find it here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=200fd7b5-db7c-4b8c-a7dc-5efee6e19005&DisplayLang=en

The SQLCAT team just released a very interesting technical note which compares the relative “scalability goodness” of Reporting Services 2005 to 2008. You can read the article just as well as I can, but here’s the executive summary, and the results are pretty impressive (bold is mine, btw)

Executive Summary

Reporting Services 2008 was able to respond to 3–4 times the total number of users and their requests on the same hardware without HTTP 503 Service Is Unavailable errors compared with Reporting Services 2005, regardless of the type of renderer. In stark contrast, Reporting Services 2005 generated excessive HTTP 503 Service Is Unavailable errors as the number of users and their requests increased, regardless of the report renderer.

Our tests clearly show that the new memory management architecture of the report server enables Reporting Services 2008 to scale very well, particularly on the new four-processor, quad-core processors. With our test workload, Reporting Services 2008 consistently outperformed SQL Server 2005 with the PDF and XLS renderers on the four-processor, quad-core hardware platform (16 cores) both in terms of response time and in terms of total throughput. Furthermore, with these renderers on this hardware platform, Reporting Services dramatically outperformed other hardware platforms regardless of Reporting Services version, responding to 3–5 times the number of requests than when running on either of the other hardware platforms. As a result, we recommend that you scale up to four-processor, quad-core servers for performance and scale out to a two-node deployment for high availability. Thereafter, as demand for more capacity occurs, add more four-processor, quad-core servers.

Finally, with all renderers and with all hardware platforms using our test workload, the performance bottlenecks were the processor on the front-end server and the disk subsystem on the data source with Reporting Services 2008, whereas the Reporting Services front-end Web service was the performance bottleneck with Reporting Services 2005.

It’s a whole new ballgame, folks!

Some people love to review logs. For an even smaller group, log reviewing becomes a compulsion. For those of you who fall into either bucket (or even for people like me who only look at logs if my server is spinning in circles like Regan from the Exorcist) you may occasionally see this:

w3wp!runningjobs!5!6/1/2008-12:00:00:: w WARN: Thread pool pressure. Using current thread for a work item

So, what does it mean? I attempted to explain this message to a colleague the other day, and then John Gallardo, an SDE on the SSRS team did a much better job. Here is the essence of what he said:

When a report is processed by Reporting Services, we do our best to separate the work it takes to persist “report meta data” (my words, not his) like the snapshot we store in reportservertempdb and the work involved in actually getting a report to your users. Doing so gets the report back to the user faster. Essentially, we save that snapshot data asynchronously on a different thread from the main report request whenever there are available threads to do so.

If your system is under pressure we don’t grab another thread to do this “dirty work”. Instead, we synchronously process both the report and do the additional work on the same thread. The net result for you is that normally your report will take longer to get back to the requester because they have to wait for extra tasks to finish up before the report is delivered.

I saw an interesting thread today I thought I would pass along. In essence, one of my colleagues wanted to know if the twenty-ish queries behind his SSRS report would all fire at the same time, or sequentially.

The answer is (of course, we’re Microsoft) “it depends”. Robert Bruckner from the SSRS product team pointed to the “Use Single Transaction” option on the data source properties dialog in Report Designer. If  this option is enabled (it’s disabled by default), then we run queries sequentially. If the option is disabled, we run in parallel assuming we have available threads in the SSRS thread pool.

Interesting stuff!