Advanced Report Design - Professional SQL Server 2005 Reporting Services - page 254

For additional assistance with specific security considerations and configuration details, use SQL Server
2005 Books Online to look up the topic “Using Reporting Services Security Policy Files.”
Errors, Warnings, and Debugging Code
When you preview or try to deploy a report, all of the expressions and embedded code in the report are
cranked through the .NET Common Language Runtime debugger and native code compiler. If no errors
are found, an assembly is built on the report server. This means that when reports execute, all of the
expression and program code actually run from compiled binaries rather than from the Visual Basic
source code.
Errors are listed in the task list if this process fails. The report designer has a quirk that can be a bit confus-
ing until you get use to it. Along with errors that prevent the code compiling and report deployment, there
is another set of information that shows up in this list. Some conditions may cause Reporting Services to be
less than ecstatic with your code but not unhappy enough to prevent it from compiling. These are called
warnings, and they appear on the task list below any errors. The confusing thing is that Visual Studio only
displays this list when errors occur. This means that I can build a big, elaborate report that runs perfectly
until I make one, small mistake in my code. When I try to preview this report, I may suddenly see 30 issues
displayed on the task list. These may include “can't deploy shared datasource . . .” and “textbox42 has a
BackgroundColor set to . . . which is invalid.” If this happens to you, don't lose it . . . this is just the way
the designer works. Those warnings were there all along. Visual Basic just didn't put the list in front of
you until you committed a serious infraction. Start at the top of the list and work down until you see an
error description that makes sense. Double-click this line. In most cases, this will go to the properties for
the offending report item, allowing you to make the correction and move on.
When testing reports in the Visual Studio Report Designer, your custom assembly is loaded into memory
when it is first invoked and may not be unloaded until you exit Visual Studio. This means that if you
make code changes and redeploy the assembly, these changes may not be available to the report unless
you cycle the Visual Studio application. There are two ways to work around this. The first is to make a
point to deploy your report to your local report/web server and test it using the Report Manager. The
other method is to use the stand-alone report preview utility and test it using the Report Manager.
I have found that under some conditions the report designer may display errors from other reports in
the project or errors that may have been recently corrected. If you see behavior like this, close and
reopen Visual Studio.
Designing for Mobility
The idea of making reports available in custom applications that run over the Internet or letting users
access reports from desktop computers outside of the office opens many doors of opportunity that were
not before possible. These capabilities are now very easy to achieve, but the promise of this technology
doesn't stop there. This brings to mind the unforgettable words of Ron Popeil, “. . . but wait. There's
more. . . .” Another very quotable figure, Bill Gates, announced in 2000 that the next generation of
services from Microsoft would enable people to access information “any time, any place and on any
device.” This product fulfills that promise, making reports available to the next generation of mobile
computing devices.