This article shows how to download and install Report Builder 2 on a local machine. For a good article on how to enable the product on a Reporting Services 2008 instance, see the following SQL Server Magazine article (subscription required):

http://www.sqlmag.com/article/reporting-services/report-builder-2-0.aspx

You can download the application from Microsoft at the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9f783224-9871-4eea-b1d5-f3140a253db6&displaylang=en

After downloading the file ReportBuilder.msi to your target system, double click it to begin the install process. You will be walked thought the usual license acceptance and user name dialog. However, when you get to the form looking for the default report server pause. If you have an instance of Reporting Services 2008 in your organization where you can save reports to a “My Reports” folder, enter the URL here. The URL is usually in the format “http//someserver/reportserver”. If you leave this blank, Report Builder will default to saving RDL files to your local documents folder instead.

After the installation is finished, you can find the application in your start menu under “Microsoft SQL Server 2008 Report Builder 2.0″. Launch the application and you will be greeted with the main window that looks like the following. In future posts, I will go into how to connect to databases and create simple reports.

declare @MyNames table (FullName nvarchar(20));
insert @MyNames
values ('Betty Ferguson'),('Sam L Jackson'),('Horatio Alger');

Note that I used the much simpler SQL Server 2008 syntax to add the names. If you are using SQL Server 2005, you will need to add the names like this:

insert @MyNames
values ('Betty Ferguson');
insert @MyNames
values ('Sam L Jackson');
insert @MyNames
values ('Horatio Alger');

Since you can’t control people adding a middle initial, I will find the last name by counting the number of characters starting from the right before I find a space character. The best function to use for this is charindex.

select charindex(' ', FullName) as 'LastNameLetterCount' from @MyNames;

The problem is that the charindex function counts from the left. In order to count from the right, I need to flop the text over by using the reverse function. This function will take a string of characters such as ‘My dog spot’ and return it as ‘tops god yM’. I also subtract 1 so that I only return the length of the last name, not the last name and the space.

select charindex(' ', reverse(FullName))-1 as 'LastNameLetterCount' from @MyNames;

This returns the following values:

LastNameLetterCount
——————-
8
7
5

Now I have the length of our last name. With this value, I can use the ‘right’ function to isolate the last name value. This function will return the number of characters we indicate starting from the right. For instance right(‘My String’,3) will return ‘ing’.

select right(FullName, charindex(' ', reverse(FullName))-1) as 'LastName' from @MyNames;

This will return the values:

LastName
———————
Ferguson
Jackson
Alger

However, I want to order by this field, not display it. To do that, I move the string functions to the ‘order by’ clause and only display the original field.

select   FullName
from     @MyNames
order by right(FullName, charindex(' ', reverse(FullName))-1);

This will return the requested field in the desired ascending order:

FullName
——————–
Horatio Alger
Betty Ferguson
Sam L Jackson

Of course to sort in reverse order, I could add the ‘desc’ flag to the order by clause:

select   FullName
from     @MyNames
order by right(FullName, charindex(' ', reverse(FullName))-1) desc;

FullName
——————–
Sam L Jackson
Betty Ferguson
Horatio Alger

You may have noticed the holes in this approach, such as the field only containing a first name, a two part last name, etc. However, for some quick querying on a known data set, this technique may get you pretty far.

In the last post, we used a subquery to only show the latest value in a table that has a time component. The table holds an employee’s pay rate history and includes a “RateChangeDate” field. Although our use of a subquery makes sense, over time it will become tedious to type the same code every time we want to show an employee’s current pay rate. In addition, the use of the subquery adds risk to the quality of our application. The business logic represented by the subquery will need to be tested every place the subquery appears, increasing the odds for an error down the road.

Since we know the subquery is a handy block of code, we will take advantage of a common database feature called a “view”. In a nutshell, a view is a persistent select query that is given a name and can be referenced just like a table. With a view, business logic can be defined once and shared between future queries and even between programmers.

Taking our last example, lets turn the subquery for the latest pay rate and turn it into a view. Note how we use the “create” statement just like when making a table.
create view HumanResources.CurrentEmployeePayrateView
as
select    e.EmployeeId
          ,eph.Rate as Payrate
from      (
               select   EmployeeId
                        ,max(RateChangeDate) as RateChangeDate
               from     HumanResources.EmployeePayHistory
               group by EmployeeId
           ) e
inner join HumanResources.EmployeePayHistory eph on e.EmployeeId = eph.EmployeeId
                                    and e.RateChangeDate = eph.RateChangeDate


Now we can replace the subquery in our query from the last post with a reference to our view like this:
select       e.EmployeeId
             ,c.LastName + ', ' + c.FirstName as EmployeeName
             ,e.VacationHours + e.SickLeaveHours - 120 as AccruedPtoHoursInExcess
             ,cast((e.VacationHours + e.SickLeaveHours - 120) * f.Rate as decimal(6,2)) as Liability
from         HumanResources.Employee e
inner join   Person.Contact c on e.ContactId = c.ContactId
inner join   HumanResources.CurrentEmployeePayRateView f on e.EmployeeId = f.EmployeeId                            
where        VacationHours + SickLeaveHours > 120;

A couple of notes: The view acts like a table in more ways than one. You can set permissions on it for specific user by using the “grant select” statement just like on a table. It is also possible to put an index on a view, but I do not recommend this for beginners as an index on a view can become complicated to manage.

There are times when you need to perform a calculation on values stored in two different tables. The first value is stored in a summary level table, and the second is stored in a detail table. I will use the Adventure Works employee tables to demonstrate.

Let’s say you need to calculate the accrued vacation time for your employees that exceeds the company limit of 120 hours and derive the total liability to the company in terms of dollars. Using the Adventure Works database, that would require three tables: HumanResources.Employee, Person.Contact, and HumanResources.EmployeePayHistory. To start, we know we need to identify the employee so we include the EmployeeId field from the Employee table and the LastName and FirstName fields from the Contact table. Make sure and include the schema when declaring the tables, as this is required for any schema that is not ‘dbo’. This is a good practice anyway. Also, note the use of the table aliases ‘e’ and ‘c’ to save typing and add clarity.

select      e.EmployeeId
            ,c.LastName + ', ' + c.FirstName as EmployeeName
from        HumanResources.Employee e
inner join  Person.Contact c on e.ContactId = c.ContactId

Now we can easily calculate the accrued hours by adding two fields from the employees table: VacationHours and SickLeaveHours. We are assuming the business definition for the field is ‘hours accrued’, but this would need to be confirmed with the business owner. Since the column does not allow nulls, we do not need to trap for that using the ISNULL or COALESCE function. However, don’t forget to subtract the acceptable limit of 120 so we only see the delta.

select      e.EmployeeId
            ,c.LastName + ', ' + c.FirstName as EmployeeName
            ,e.VacationHours + e.SickLeaveHours - 120 as AccruedPtoHoursInExcess
from        HumanResources.Employee e
inner join  Person.Contact c on e.ContactId = c.ContactId

Since this will result in negative numbers for employees that have not accrued at least 120 hours, we might decide to trap that using the CASE statement and only return either a zero or a positive number. For our purposes, though, it makes sense to just show employees with a positive number. We will add a WHERE clause to limit our list. As a good practice, you should limit your results earlier in your development process or risk overburdening your database with an oversize result set. If you do not what your WHERE clause will be, you can still add a TOP declaration to your SELECT statement and limit the results to a manageable number of rows.  It is also a good idea to end your T-SQL statements with a semicolon, so I added one to our query.

select      e.EmployeeId
            ,c.LastName + ', ' + c.FirstName as EmployeeName
            ,e.VacationHours + e.SickLeaveHours - 120 as AccruedPtoHoursInExcess
from        HumanResources.Employee e
inner join  Person.Contact c on e.ContactId = c.ContactId
where       e.VacationHours + e.SickLeaveHours > 120;

Now for the tricky part. The pay rate for the employees is stored in the EmployeePayHistory table, but the table has a time component. In other words, there is a record added every time the pay rate changes. If we just add the table like follows, then we risk returning more than one record for a single employee. Note the new formula to caculate liability. I use parenthesis to enforce the correct order of operations:

select      e.EmployeeId
            ,c.LastName + ', ' + c.FirstName as EmployeeName
            ,VacationHours + SickLeaveHours - 120 as AccruedPtoHoursInExcess
            ,cast((VacationHours + SickLeaveHours - 120) * eph.Rate as decimal(6,2)) as Liability
from        HumanResources.Employee e
inner join  Person.Contact c on e.ContactId = c.ContactId
inner join  HumanResources.EMployeePayHistory eph on e.EmployeeId = eph.EmployeeId
where       VacationHours + SickLeaveHours > 120;

In my database, the latest query increases the row count from 97 to 99 because Rob Walters ends up with three records. We could just assume that Rob’s pay rate always increases, but that is prone to error. Instead, we need to add a subquery to only filter on the latest pay rates for each employee as determined by the RateChangeDate. The following query provides the filter we need:

select   EmployeeId
         ,max(RateChangeDate) as RateChangeDate
from     HumanResources.EmployeePayHistory
group by EmployeeId

Now, all we need to do is add this into our main query so that it acts like a filter table, and join the original  EmployeePayHistory table to the derived filter table instead:

select      e.EmployeeId
            ,c.LastName + ', ' + c.FirstName as EmployeeName
            ,VacationHours + SickLeaveHours - 120 as AccruedPtoHoursInExcess
            ,cast((VacationHours + SickLeaveHours - 120) * eph.Rate as decimal(6,2)) as Liability
from        HumanResources.Employee e
inner join  Person.Contact c on e.ContactId = c.ContactId
inner join  (
                select   EmployeeId
                         ,max(RateChangeDate) as RateChangeDate
                from     HumanResources.EmployeePayHistory
                group by EmployeeId
            ) f on e.EmployeeId = f.EmployeeId
inner join  HumanResources.EmployeePayHistory eph on f.EmployeeId = eph.EmployeeId
                                                    and f.RateChangeDate = eph.RateChangeDate
where       VacationHours + SickLeaveHours > 120;

The query now returns our original 97 rows and shows the current liability which is defined as ‘the current pay rate times the accrued PTO over 120 hours’.