Add an expression to a report in .NET framework

Printer QR Code in .NET framework Add an expression to a report

In this part: 16: Report Authoring with Custom Development . . . . . . . . . . .433 17: Programming Report Server Management. . . . . . . . . . . . . .471 18: Building Custom Reporting Tools . . . . . . . . . . . . . . . . . . . . . .499

In Part IV, Delivering Reports, you completed the final stage of the reporting life cycle using Reporting Services. Now, in Part V, you begin the reporting life cycle again, but in these chapters, you ll look at how to author, manage, and deliver reports programmatically. Because Reporting Services has an extensible architecture that uses an open schema for reports and a published application programming interface (API), you can add as little or as much customization as you need to fully support the information requirements of your organization.

16

After completing this chapter, you will be able to:

Use custom code in expressions. Create a custom data processing extension. Generate a report definition programmatically.

This chapter explores the types of authoring activities that you can customize. You ll learn how to reuse custom code in your report to handle complex functions either as embedded code or as a custom assembly. You ll also learn how to build a custom data processing extension to read XML data and how to incorporate that data processing extension into a program that builds a report.

When you need to use a complex expression many times in a report, it s usually easier to write the code once as a custom function, and then refer to it as needed. By following this practice, you can minimize the number of places in the report requiring updates if you later want to modify the expression. In particular, you can write procedural code in your custom functions to take advantage of loops using FOR or WHILE, or conditional logic using IF THEN or CASE statements. You can reference custom functions anywhere that you can use an expression to control report item values, styles, and formatting. One way that you can implement custom functions is to embed code in your report. However, with this approach, only the report in which you embed the code has access to the custom functions. Also, the embedded code must be written using Microsoft Visual Basic .NET. Another approach with custom functions is to create a custom assembly that can then be referenced by any report. A custom assembly can be written using any language supported by the Microsoft .NET Framework.

Part V:

By adding custom code to your report, you can build in additional functionality to expand upon the features provided by Reporting Services. For example, a common issue that must be dealt with in reports that use ratios is the prevention of divide-by-zero errors. In 5, Working with Expressions, you created an expression to add a margin percentage to the Product Sales and Profitability report. This expression used the following code in the detail row: =ReportItems!Margin.Value/ReportItems!SalesAmount.Value, which, in this case, is equivalent to =Fields!Margin.Value/Fields!SalesAmount.Value. Whether you use the ReportItems or the Fields collection to build this expression, the risk is that a record in the dataset will have a zero value for SalesAmount. It s a common programming practice to test a value for zero before you use it as a denominator in a division operation. Your inclination to fix the expression would probably be to write some code that looks like this: =IIf(Fields!SalesAmount.Value=0,0,Fields!Margin.Value /Fields!SalesAmount.Value). However, Visual Basic .NET evaluates each argument individually if one argument fails, the whole expression fails. (You can test this with =IIf(true,1,0 /0) to confirm that, even though the argument is not returned, the division by zero makes the entire expression fail.) One approach to solving this problem is to write a custom function to test the denominator before performing the division. Using this method, you still use IF logic to test the denominator before performing the division, but you do it with procedural statements rather than in a single function. This prevents the division if the denominator test fails. The code for this function is then embedded in the report definition and can be referenced by any expression in the report. In this procedure, you ll embed code to prevent errors caused by dividing by zero. Embed code in a report 1. Start Microsoft Business Intelligence Development Studio and open the Custom solution in the C:\Documents and Settings\<username>\My Documents\Microsoft Press \rs2005sbs\chap16 folder. 2. In Solution Explorer, double-click the Order Profitability Embedded report.

16: