Phil Simon's Virtual Soapbox » Reporting

Suppressing values to minimize the number of tables in a Crystal Report

philsimon — Mon, 02 Feb 2009 07:53:56 +0000

A simple rule of reporting is that adding tables and views increases the amount of time for the report to run. Many first-time report writers believe that you have to add multiple instances of a table in order to derive different totals, such as month-to-date, year-to-date, etc.

You don’t.

Check out the .pdf below to see an example of how to maximize the performance of a report with a single instance of a transactional table.

Suppressing values to minimize the number of tables in a Crystal Report.

One Report, Multiple Report Output Options in Crystal Reports

philsimon — Mon, 02 Feb 2009 07:33:49 +0000

One of the disadvantages of using groupings in a single Crystal report is that the export into Excel makes the data “unsortable.” However, there is a neat way around this. You can use the suppressing section functionality to, in one report, prompt a user if they want to export it cleanly to Excel (suppressing all of the groupings). This is great if end-users want one report with different output options. The one downside is that you couldn’t schedule this in many tools because report needs the prompt – export to Excel yes/no.

This tip addresses of one of the biggest challenges that consultants have with clients:

Trying to minimize the number of custom reports required by the organization.

Report-creep may not be a widely-used term but I have seen people request two different reports for essentially the same information. The PDF below walks you through how to use one report in multiple ways.

One Report, Multiple Report Output Options

Crystal Reporting: A Case Study

philsimon — Wed, 29 Oct 2008 08:24:21 +0000

A client of mine recently had an interesting reporting request: Does Lawson have a standard report detailing any changes in employee status and the personnel actions (excluding rehires and new hires) associated with them?

Note that this case study applies to the Lawson application but just as easily could be applied to any custom report question.

The answer was no. You know the next question: Can you write me a report detailing any changes in employee status and the personnel actions (excluding rehires and new hires) associated with them? And, while we’re at it, can that report have a date range? And can you exclude the terminated status?

That was my task, using Crystal Reports XI and LRS. Now, normally this wouldn’t be so hard. For those of you familiar with the Lawson tables, you know that status (if set to track history on HR10) is located on the HRHISTORY table (FLD_NBR = 20). This report request, however, had a little wrinkle that made it a bit more challenging than normal: some personnel actions may have had status changed on the employee and some may not. In other words, one couldn’t always say that the POSITION personnel action always had status changed.

There was one more little wrinkle: all employees were loaded into Lawson via the HR511, not via PA52.4. In other words, employees’ initial HRHISTORY status value was not tied to a personnel action. In technical terms, you couldn’t just join EMPLOYEE to PERSACTHST to HRHISTORY to get the desired results. Even as outer joins, the report would not work. I would have to get creative.

First Things First: Group by Employee

I began building my report with the EMPLOYEE table. To make this report work, I first need to group this by employee. This step is necessary to enforce the date range (as we will see later), as employees may have had status date changes over the last five years but an end-user may only want to see them from the last pay period.

Using the group expert, we can accomplish this:

Note that this report also has a department group.

Joining Tables

The remaining tables for this report are: PERSACTHST, HRHISTORY, and DEPTCODE.

Note that I did not build this report using the Lawson OLEDB Connector. HRHISTORY is a very, very large transactional table with hundreds of thousands of records (and growing). I used a SQL OLEDB connection which does not enforce Lawson security. This was not an issue for the client.

I then joined the tables as follows:

The order of the joins is imperative here. By going from EMPLOYEE to HRHISTORY (with FLD_NBR =20) in the Select Expert as an inner join, I am only pulling employees who have had status changes. The left outer join from HRHISTORY to PERSACTHST, in English, means that the report will retrieve status change values whether they were part of a personnel action or not.

Now that I have the tables joined properly, I can continue building my report.

The counterpart to the employee group is a “maximum effective date” calculation:

I then put the maxdate formula in the Employee group header:

Filtering Data with the Select Expert

I restricted the dates by adding a parameter and referencing that parameter in the select expert:

I tied this parameter to my maxdate calculation so this report can be run to only pull employees who have had status changes in the past X weeks.

Since I am only interested in changes in status, I added a count of BEG_DATE in the employee footer.

I then set that count greater than 1 in the select expert. Remember, I don’t want to see employees with only one value in HRHISTORY for status; they couldn’t have had a change! This is the case because history was loaded via HR511 (Lawson’s employee conversion program.)

I was only interested in three cases (LEAVE personnel action, POSITION personnel action, and “no” personnel action for history changes). The client didn’t want terminated statuses include or REHIRE and HIRE personnel actions. To accomplish this, I had to use a slightly involved “OR” statement in the Select Expert:

(EMPLOYEE.EMP_STATUS} in ["01", "02", "03", "04", "05","06"]
AND {HRHISTORY.FLD_NBR} = 20
AND {HRHISTORY.A_VALUE} <> “08″
AND (ISNULL ({PERSACTHST.ACTION_CODE}) OR {PERSACTHST.ACTION_CODE} IN ["POSITION", "LEAVE"]))

Results

Running the report gives me the following prompt:

and the following results:

Voila!

Creating Commands in Crystal Reports via Microsoft Excel

philsimon — Sat, 19 Jan 2008 12:43:02 +0000

Many times, transactional tables in databases are big. I mean, huge. I have seen tables with 35,000,000 records. Imagine writing a report with four or more tables and the data resides in monstrous tables.

Let’s be clear here. There’s only so much that you can do when you have really big data sets. By the same token, however, often you can reduce the run time for large reports by using commands in Crystal Reports.

In the following PDF, see how I use Microsoft Excel to create a command in Crystal. This ultimately saves a great deal of time when the report runs.

Using SQL-Based Commands in Crystal Reports