A developer asked a question on MSDN that was similar to a question a few days earlier so I decided to help folks get over the problems of setting report parameters in ReportViewer projects.
Recently in Reporting Services Category
My new webinar/lab class launches next week on February 8-10. It’s the premier edition of a series of lectures and lab exercises that walk report developers through the process of learning enough Visual Basic to create serious report expressions for use with Reporting Services reports.
We follow the introduction to Visual Basic with an in-depth discussion of how to add code-based expressions to your reports, but more importantly, how to share the code between reports. The final session shows how to create managed-code DLLs that can be developed in C#, VB.NET or any .NET CLR language and leveraged by the report processor when rendering your report.
The mentored lab exercises walk you through the process of creating a Visual Basic test-harness, coding and debugging complex code expressions and finally, you’ll create your own sharable managed-code DLL that can be used in all kinds of deployed reports.
Here’s the link to the Progressive site.
I’m prepping for my webinar next week that includes new content on Reporting Services SharePoint Integration and I came across a problem. In Report Manager I can easily “move” a report from folder to folder—it’s just a point-and-click operation with a GUI interface that shows the destination folder. I tried to do the same with SharePoint and discovered that there is no “move”—just a copy operation that’s a lot harder to use and not nearly as intuitive as it should be.
This entry focuses on the code developers add to reports make them work, look better or expose custom functionality. Sometimes it’s simply adding green-bar but when these expressions get complex or have to be incorporated in many places in the report or in many reports (or both) productivity suffers.
Just thinking aloud here. So, let’s say you have a team of report developers and you find that more than one report needs to access a common set of routines.
Note to self (and anyone else using RS Scripter to backup/transport a Reporting Services catalog): If you get a permissions error when scripting, try un-checking any User folders that you don’t own. Apparently, it can’t access other user’s reports when scripting.
I’ve been working with the new “2008 R2” Reporting Services BI tools (which generate 2010 RDL) that get installed with the latest release of SQL Server. Ah, I have a pretty good idea why Microsoft chose to release this “sub-release” instead of a “2010” version, but I’ll leave that discussion to another post. At this time (unless its already too late) I would like to provide a few suggestions for the Reporting Services team working on the 2011 version of the BI tools. Sadly, I expect that these tools are cast in stone somewhere on campus or on the other side of the world…