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.

Yesterday, the fine folks at Microsoft added an evaluation version of PAS 6.3 to the already available ProClarity Desktop 6.3 eval. You can download it here.

A few notes about this release:

·         ProClarity Analytics Server 6.3 – Evaluation contains the RTM version of the product; it does not include any of the ProClarity 6.3 hotfixes or cumulative updates.

·         You cannot upgrade this evaluation version with any PAS hotfixes or cumulative updates.

·         Support for this product (via the ProClarity TechNet forum only - http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=1870&SiteID=17.) will only be available if no PAS updates have been applied.

·         This product contains only the server components of ProClarity Analytics Server 6.3—that is, the PAS Administration Tool and the thin client, ProClarity Web Standard. It does not include ProClarity Dashboard Server 6.3 or the following ProClarity 6.3 add-ins: ProClarity Web Professional, ProClarity KPI Designer, or ProClarity Selector.

·         To publish briefing books to PAS, you  are expected to use the evaluation version of ProClarity Desktop Professional 6.3.

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

Sheesh, take a day off from reading mail and you miss the chance to blog about one of the most important products on the day it RTMs. I’m a day late and a dollar short, but SQL 2008 released yesterday. It is build 1600.22, and I see it is already out on MSDN. It also appears to be available on connect.microsoft.com for TAP customers.

My next project is to install on PPS on a Windows 2008 VPC runing SQL 2008 and see what happens. I know neither of those are supported yet, but it appears that I should be able to get it to work using a couple of tricks.

I’ll post more details later!

Sorry, couldn’t resist!

Yesterday (or maybe it was the day before, I forget), the next rev of AllUp was released internally at Microsoft. It includes 3 new demos including a “deep dive” around PPS Planning, and new stuff for the manufacturing and hospitality sectors.  The image will expire around 12/4/2009.

The super-awesome product manager responsbile for this work of art says that it still needs to get a buy off from our legal department, so isn’t available to partners quite yet - but it will be soon!

I spent a chunk of time this morning scratching my head when I couldn’t get PerformancePoint Monitoring & Analytics display actions working in MOSS. They worked fine in certain dashboards I had  already published, but different dashboards published to the same site were broken - display actions didn’t work at all.

I finally got my “misbehaving” dashboards working by employing the following tactics in the Dashboard Designer:

1. Open the Scorecard that contains the KPI your display condition will leverage.

2. On the Edit tab, Update the scorecard.

3. Go back to your dashboard and add/remove/whatever the display condition in question.

4. Publish/Save.

5. Repeat for each display condition you want to work with.

I don’t know if step 5 is strictly necessary, but I spent so much time on this I didn’t want to experiment any more - just needed to get on with my life! I haven’t tested to see if this is fixed in SP1, but hopefully it is!

While building out some dimensions today, I ran into the following error while using Planning Business Modeler. The error occurred when I selected the name of a table/view in my data source:

Server failed to return the table schema from source database. (Error code: PerformancePoint_225000210). Getting table schema for table <table name> from database <database> on server <server> failed.

Turns out PPS can’t handle any tables or views which are not part of the dbo schema. I had a few of them, and had to use the command below to swap the schema each object belonged to before I could get them into PPS.  I suppose I could have created a dbo.View on top of each object, but I was being lazy:

 ALTER SCHEMA dbo TRANSFER someschemaname.tablename

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.