Crystal Reports: Report Header Tips

crystal reports viewers, crystal reports schedulers, view crystal reports, report analyzers, burst reporting, report scheduler

Home | Contact | Articles | Products || Support | Search

Analyzers | Schedulers | Viewers | More Crystal Reports Tools

Crystal Reports Tools: Improve Performance While Saving Time and Money

	Resources
	Best sellers: cView Report Analyzer cViewSERVER ReCrystallize

	Articles: Administration Advanced Basic Crystal eNL Database Financial Problems Solved Books: CR Books Database Books Developer Books
	Tools: Analyzers Bestsellers CR Schedulers CR UFLs CR Viewers DataBase Tools Graphics International Mail UFLs ReCrystallizePro
	Add'l: About us Contact Us cViewSUITE Ppt Support
	CrystalReports on Steroids

Crystal Reports: Report Header Tips

We have this one tip, so far. And it's a great one.

Page numbers in a large Report Header section

This request asked how to get page numbers on a large Report Header section. The report designer had a lot of initial information to display in the Report Header section, and sometimes this overflowed to a second, or even a third page. Page numbers didn’t appear correctly for those first few pages.

You can’t move the objects to a Page Header section, as this section cannot be larger than the page size.

So our recommended approach was to place them in sections Group Header 1a, 1b, etc.. Set that group to “Repeat on Each Page” and conditionally suppress those sections using the formula:

GroupNumber > 1 or InRepeatedGroupHeader

The only problem now is if the report doesn’t find any data. The Group Header sections will not display. If this is likely, create a report with one record and this structure and then do the other processing in a sub report.

Thanks to Mark Richardson and Kurt Rheinhardt for an interesting discussion on this.

So, what about subreports? These are common database tools that serve as intermediaries when you can’t create a report directly from multiple data sources. In Access, for example, doing anything across multiple queries or tables requires building a subreport. Crystal Reports doesn’t need the same degree of subreport "propping up" that Access does, but it still makes handy use of subreports.

Suppose you have two databases, where each stores the same information—such as employee names, addresses, start dates, and so on. But, the one uses the date format YYYY-MM-DD and the other uses the date format MM-DD-YY.

Hmm. Small problem, here. Suppose one table store numbers in a true number field and the other stores them as string variables or text. The only way to resolve such incompatibilities is with a subreport. You create one subreport to standardize the data in one database to the format of the data in the other. Or, if you’re feeling particularly masochistic, you create a subreport for each database, coming up with an entirely new format.

Subreports can be linked (they update data as those data change in the source) or unlinked (they contain static data). You would want a linked report if you want "real time" information. You would want a static report under any of these conditions:

You simply lack the space for the larger file created by a linked file.
You won’t have access to the source file, thus you cannot keep the files linked.
Your report focuses on a specific period. For example, if you are reporting last year’s sales and it’s June now, you don’t want new data.

Among linked reports, a increasingly popular option is the on-demand subreport. It doesn’t process until you ask it to. It can appear as just a link or some other element (such as a graphic that says, "Update data now.") This has all kinds of benefits which will become apparent as you use it.

For even more functionality, you can use third-party programs, such as the ones available here.

Nothing says you have to start designing with subreports right away. In fact, it's probably best that you wait until you have some experience with general report design.

That's because subreports are an advanced feature. Learning to use them is well worth your time, though, because they can solve some complex database reporting problems. These include:

Data for the report are coming from more than one data source
Table joins cannot be used to retrieve the required records
Several views of the same data are required

If you have these problems, display some of the report as a main report and the remainder in one or more subreports.

Then you have an important design decision to make. Which part of the report do you do in the main report, and which parts do you want in subreports?

We suggest the following approach:

The main report must do the primary record selection and grouping. You cannot group or select data based on values in the subreport. The subreport is then used complete the missing values–essentially "fill in the blanks."

One extension to this approach is to use a subreport to retrieve a value, and then use conditional formatting in the main report that uses the subreport information. But there are limitations to this:

The subreport has to take up some vertical space in the report.
Subreports in suppressed sections do not get processed, so any shared variables expect from them will not be calculated.

Before you start doing subreports as a standard practice, give yourself some time to learn by doing on a smaller scale. This will allow you to come up with your own style guide and standards for using them. The consistency and standardization will pay off in the long run, if not sooner.

This article is copyrighted by Crystalkeen, Mindconnection, and Chelsea Technologies Ltd. It may be freely copied and distributed as long as the original copyright is displayed and no modifications are made to this material. Extracts are permitted. The names Crystal Reports and Seagate Info are trademarks owned by Business Objects.