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.

Yesterday, my buddy Amit Panchal and I were trying to get an x64 instance of SSRS joined to reporting farm, and had a bear of a time.

Because of issues I won’t get into here, we were trying to initialize the server in the “classic” way – meaning we had exported our encryption key from one of the other nodes, copied it to the new machine and were trying to apply it locally, ala:

RSKeyMgmt.exe -a -f C:\Keys.snk -p password!

We kept on getting the error:  The report server installation is not initialized. (rsReportServerNotActivated)

We spent a couple hours trying to troubleshoot this using RsKeyMgmt -j, trying the same thing in the SSRS config tool, and so on. Still, we had no luck.

On a lark, we re-exported the key from the same server as before, copied it over and tried again. It worked like a charm! Next, we tried the old key again, and splat, same error. Moral of the story is that it appears every now and then your key might get munged during the export and/or copy process. 

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!