2/15/2012

Adding Custom Code to the Reporting Services 2008 R2

By

There are numerous circumstances when we wish to add a custom function to a SSRS report in order to cater for needs of the customer which exceeds the capability of the built-in functions in SSRS. In these scenarios we will have to write our own functions. In this article I will demonstrate how to add custom code to SSRS.

Using SQL Server 2008 R2 Business Intelligence Studio

 Using Custom Code inside a report:  In this article we will consider a scenario where we want to design a KPI using custom code inside a report using the code tab of the report properties. For this we will have to write the below VB code as VB is the only language currently supported for the custom code in SSRS. Create a new SSRS project in BIDS studio and add new item as a report from the templates.
1. Create a dataset using AdventureWorks as datasource the following query:

SELECT  top 1   Name,  StandardCost, ListPrice, ListPrice - StandardCost AS ProductProfit
FROM    Production.Product
WHERE   (StandardCost >= 1000)
2. Select Report-> Report Properties from the menu.

3. Select Code tab from the report property window

4. At present only VB  supported for writing  custom code inside the report. Copy and paste the below code in the code window and click ok:

 Public Shared Function Test(ByVal profit As Decimal) As String
        Dim st As String
        If profit >= 1000 Then
            st = "High Profit"
        ElseIf profit >= 500 Then
            st = "Moderate Profit"
        Else
            st = "Average Profit"
        End If
        Return st
   End Function
5. Right-click on the textbox  and go to expressions.

6. To call the function written in the custom code window you will have to enter  Code.FunctionName . In the expression in our example it would be something like this:
=Code.Test(Fields!ProductProfit.Value)
7. The final Output should be something like this.

 Using Custom Assemblies:
The custom assemblies can be created using a class library project to create more advanced functionality for your reporting solution. The code reference for function to be used in the reporting services can be given in the references section in the report properties. To do this create a custom assembly and create a class library project called TestClass and add the below code to it:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace TestClass
{
    public class Class1
    {
        public static int Cal(int a, int b)
        {
            return a + b;
        }
    }
} 
 
Compile the code to generate the TestClass.dll file. To access the code inside this file we need to place this dll  in the default location of the Report Designer which is  \Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies.
To add a reference to the file inside the report perform the following steps:
1. Select Report-> Report Properties from the menu.

2. Select the Reference  tab from the report property window

3. Add a reference to the TestClass.dll by browsing to the location of the default report designer i.e \Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies

4. Add the following code in the expression of the textbox of the tablix.

=TestClass.Class1.Cal(3,4) This code calls the function defined in the assembly reference. Here you don’t need to use the Code keyword to access the function defined in the Custom assembly. You can also define an instance of the class used in the custom assembly but this is optional as you can access the function using the namespace.classname.functioname inside the expression as shown below:-
5. The output should be as follows

For the custom code to be working after deploying the report you will need to paste the testClass.dll  – i.e the dll file in the bin folder of the reporting services whose default location is
\Program Files\Microsoft SQL Server\Instance_Name\Reporting Services\ReportServer\bin
Finally, just click right on the solution and deploy it on the report server to view it in the production environment.
 

Design A Hybrid Report in SSRS

By

Hybrid reports are the reports which have two types of graphs using different axes within the same graph .
For example.

In the above report, Product cost is on the right axis while Sales Amount Percentage is shown on the left axis, so that viewers can easily compare Product Cost vs Sales Amount Percentage.
Below is the query which is required for the above graph.
WITH TotalSales ( SumTotal)
AS(
SELECT  SUM(S.SalesAmount)
FROM dbo.FactInternetSales S
)
SELECT T.CalendarYear,SUM(S.TotalProductCost) TotalProductCost,
100 * SUM(S.SalesAmount)/ MAX(TotalSales.SumTotal)  SalesAmountPercentage
FROM dbo.FactInternetSales S
INNER JOIN DimTime T ON S.OrderDateKey = T.TimeKey
CROSS JOIN TotalSales
GROUP BY T.CalendarYear
ORDER BY T.CalendarYear
You can use the AdventureWorksDW sample database to get the above data.
To start the report , create an SSRS project and add a data source and a data set with the above query.
Next, add a chart control to the report. So your report should look as below:

Then drag the Calender Year to the X axis and TotalProductCost and SalesAmountPercentage to the graph area and your report should look as below:

Then select the SalesAmoutPecentage as shown in the above graph and change the graph type to Line by right clicking and selecting Change Chart Type.
You will see following configuration, if you look closely you will see that in the chart data and chart type has changed.

Right-click and select Series  Properties and you will be taken to the following dialog:

From here you can select the Secondary option from the Axes and Chart Area.
Finally, you can change the marker to complete the process.

Implementing Transactions in SQL Server – Part II

By

In Implementing Transactions Part I I briefly described the role of Transactions in SQL Server and outlined a very basic implementation. In this second part, I will explain how a DBA can best implement Transactions in scripts that are to be deployed on production databases.
One of the regular tasks of a DBA is to generate database schema change scripts, and then deploy the scripts to SQL databases. If an organization is not using a third-party tool, as is common, then Database Professional (which is part of Visual Studio from Microsoft) is normally used to accomplish this task. In many companies, the process of generating schema change scripts is a daily routine. Create DB scripts are generated on from TFS, a schema compare is performed between the previous and the latest build, and the schema update script is generated. The only issue is they do not run as a single transaction. The reason is that the scripts that are generated do not have explicit transactions defined. Unfortunately it is not simply a matter of defining a transaction using BEGIN TRANSACTION, and based on the @@TRANCOUNT variable in the end of the script either perform a Rollback or a Commit. This is due to the fact that after every DDL statement, DBPro inserts a GO statement, causing each statement to run as a batch, and explicit transactions do not span multiple batches. A sample script that is generated by DBPro would be similar to this:
PRINT N'Creating [dbo].[test1]'
GO
CREATE TABLE [dbo].[Test1]
(
[Col1] [bigint] NOT NULL IDENTITY(1, 1),
[Col2] [int] NOT NULL,
[Col3] [varchar] (50) NOT NULL,
[Col4] [varchar] (50) NOT NULL
)
GO
PRINT N'Creating primary key [PK_Test1] on [dbo].[Test1]'
GO
ALTER TABLE [dbo].[Test1] ADD CONSTRAINT [PK_Test1] PRIMARY KEY CLUSTERED  ([Col1])
GO
PRINT N'Creating [dbo].[usp_SP1]'
GO
CREATE PROCEDURE [dbo].[usp_SP1]
AS
…..
ALTER TABLE [dbo].[Test2] ADD [Col1] VarChar(100)NULL
GO
If there are no syntax errors in any of the DDL statements, then all the statements will run successfully. If, however, any of the statements results in an error then we have issues. Let’s say, the sample script above fails at the following statement because the table dbo.Test2 doesn’t yet exist on the database:
ALTER
TABLE [dbo].[Test2]
ADD [Col1] VarChar(100)NULL
GO
In this case, all the statements before this statement in the script would have run successfully, and committed the schema changes on the database, and the remaining statements after this statement including this one will not update the database leaving it in an unstable state. One solution is to fix this statement and run only the remainder of the script. This is a manual step, and is fine if scripts are deployed manually to the database. But what if there are a series of scripts being deployed at a time using an automated process?
There are several options to address this:
Option 1 : Remove all the GO statements from the scripts and then wrap the entire script within a single explicit Transaction. This involves manually editing the files which may not be feasible if the files are very large in size with numerous GO statements.
Option 2 : Implement transactions. Didn’t I mention earlier it is not possible because of the GO statements? Actually it is possible with a little bit of tweak, and the use of a SET option in the script. In SQL Server, there is a SET option called SET XACT_ABORT. This option specifies whether SQL Server automatically terminates and rolls back a Transaction if a T-SQL statement raises a runtime error. The default option is OFF. But, if it is set to ON, the entire transaction is terminated and rolled back.
To avail of this the above above sample script can be rewritten as below:
:On Error Exit
SET XACT_ABORT ON
GO
Begin Transaction
      PRINT N'Creating [dbo].[test1]'
      GO
      CREATE TABLE [dbo].[Test1]
      (
      [Col1] [bigint] NOT NULL IDENTITY(1, 1),
      [Col2] [int] NOT NULL,
      [Col3] [varchar] (50) NOT NULL,
      [Col4] [varchar] (50) NOT NULL
      )
      GO
      PRINT N'Creating primary key [PK_Test1] on [dbo].[Test1]'
      GO
      ALTER TABLE [dbo].[Test1] ADD CONSTRAINT [PK_Test1] PRIMARY KEY CLUSTERED  ([Col1])
      GO
      PRINT N'Creating [dbo].[usp_SP1]'
      GO
      CREATE PROCEDURE [dbo].[usp_SP1]
      AS
      …..
      ALTER TABLE [dbo].[Test2] ADD [Col1] VarChar(100)NULL
      GO
If Xact_State()=1
Begin
      Print 'Committing Tranaction...'
      Commit tran
End
Else If Xact_State()=-1
Begin
      Print 'Rolling Back Transaction...'
      RollBack Tran
End
Please note the first four lines and the last ten lines in the script.

:On Error Exit
This command causes sqlcmd to exit the sql script upon encountering an error.

SET
XACT_ABORT ON
With this statement, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back.

Begin Transaction
This statement defines an explicit transaction for the entire sql script.

If Xact_State()=1 
This statement checks for any committable transactions at the end of the script. If there are any, then Xact_State() will be 1, and the transaction will be committed in the IF block.
If Xact_State()=-1 
This statement checks if the transaction introduced in the script is in an ‘uncommittable’ state. By uncommittable, I mean if any error was encountered during the execution of the script then the script cannot continue execution, and all changes introduced in the database up to the point of failure in the script need to be rolled back. This rollback is done in this IF block.
Please note that scripts in which we introduce transactions in this manner, can only be run from the command prompt via SQL Server’s command-line utility sqlcmd. If this script is run from Management Studio, then it is possible that it will run only partially and commit only those changes where there are no errors in the script. This is because there is a difference in the behavior of execution of sql scripts when they are run from the SQL Server Management Studio, and when they are run from the command prompt since SSMS uses the .NET Framework SqlClient for execution in regular and SQLCMD mode in Query Editor . Whereas, sqlcmd when run from the command line uses the OLE DB provider. Since different default options may apply, there are different behaviors when executing the same query in SSMS in SQLCMD Mode and when exuting the query using the sqlcmd utility
This solution is good for implementing transactions in individual scripts when they are called from sqlcmd. But what if there is a requirement to run a series of such scripts which should all either commit or all roll back it is not a good solution.
We have to tweak this approach a little bit to satisfy this requirement. For this purpose we could not define the transactions in individual scripts as I have explained earlier, but call these scripts from another sql script I call as Wrapper.sql, then define the transaction in this wrapper and call the wrapper from sqlcmd.  The script would like this:
:On Error Exit
SET XACT_ABORT ON
GO
Begin Transaction
:r script_1.sql
:r script_2.sql
:r script_3.sql
If Xact_State()=1
Begin
       Print 'Committing Tranaction...'
              Commit tran
End
Else If Xact_State()=-1
Begin
       Print 'Rolling Back Transaction...'
              RollBack Tran
End
Throughout this example the concept has remained the same. The only difference is how and where to define the transaction, and how to call the scripts.