Adding Database Objects to Your Report
The term database objects is used to describe the various forms of data that can be added to a report. Specifically, Crystal Reports can use the following types of database objects as data sources for a report:
Database objects are listed underneath connections in the Data Explorer and are grouped by object type. In Figure 3.4, the various database objects are shown for the Xtreme Sample Database. In this case, there are tables, views, and stored procedures. The Add Command node gives you the ability to add SQL Commands to this report.
Figure 3.4 The Data Explorer groups database objects into categories.
The following sections describe each of these database object types in further detail.
Reporting Off Tables
Tables are the most basic form of a data structure. Although different vendors' databases have different concepts and terminologies, a table is pretty universal. Simply put, a table is a set of fields bound together to represent something in the real world. A Customer table might exist with fields that describe all the customers a given business has. An Employee table might exist that stores information about a corporation's employees such as name, title, or salary.
To add a table to a report, select the table in the Data Explorer and click the arrow (>) button. The table is added to the Selected Tables list on the right side of the dialog below its corresponding connection. Most database administrators will give the tables meaningful names; however, sometimes tables can have quite archaic names, such as RM564_321. A name like this isn't very descriptive, so it would be useful to rename this table to something more meaningful. This is accomplished by selecting the table in the Selected Tables list and pressing the F2 button (F2 is a standard convention for renaming things in Windows). In Crystal Reports, renaming a table is referred to as aliasing a table.
Reporting Off Views
A view is a query stored by the database that returns a set of records that resemble a table. Views often perform complex query logic, and good database administrators will create them to simplify the job of people (like report developers) extracting data out of the database. For example, the Top Customers view in the Xtreme Sample Database returns all customers who have sales of more than $50,000. From a report developer's perspective, views act just like tables and can be added to the report in the same way.
Reporting Off Stored Procedures
Stored procedures, in the context of Crystal Reports, are similar to views in that they are predefined queries in the database and return a set of records. The major difference is that a stored procedure can be parameterized. This means that rather than having a preset query that will return the same data every time it is run, stored procedures will return different data based on the values of parameters passed in.
Adding a stored procedure to a report works much the same way as tables and views. However, if the stored procedure has a parameter, a dialog will appear when attempting to add the stored procedure to the report. This is shown in Figure 3.5. The dialog will ask the report developer to provide values for each of the stored procedures' parameters. After this is completed and the OK button is clicked, focus returns to the Data Explorer and the stored procedure is shown in the list of selected tables. At this time, a parameter is created in the report that corresponds to the stored procedure parameter, and any values that parameter is given will be passed to the underlying stored procedure.
Figure 3.5 Adding a stored procedure with a parameter invokes the Enter Parameter Values dialog.
Reporting Off SQL Commands
When reporting from tables, views, and stored procedures, Crystal Reports generates a query behind the scenes using the Structured Query Language (SQL). This is beneficial because the report developer does not need to understand the complexity of the SQL language, but rather can just drop fields on to the report and get data back that matches those fields. However, sometimes report developers are quite experienced with databases and specifically, the SQL language. Because of this, they sometimes prefer to write their own SQL query rather than have Crystal Reports generate it for them. To learn about the SQL language, refer to Hour 22.
SQL Commands are a new feature in Crystal Reports 9. They allow the report developer to use his own prebuilt SQL query and have the Crystal Reports engine treat the query like a black box. What this means is that any query, whether simple or very complex, that returns a set of records can be used as a data source for a Crystal Report. To create a SQL Command, select the Add Command item under the database connection, and then click the arrow (>) button. This initiates a dialog that allows the user to type in a SQL query. Figure 3.6 illustrates a typical query.
Figure 3.6 Adding a typical SQL Command to a report.
After the query is typed in and the OK button is clicked, focus returns to the Data Explorer and the newly created command is represented as 'Command' underneath its corresponding connection. As with all database objects, selecting the command and pressing the F2 button will allow the user to rename the object.
A key feature of SQL Commands is parameterization. If the report developer had to create a static SQL query, much of the power of SQL Commands would be lost. Fortunately, SQL Commands in Crystal Reports 9 support parameters. Although parameters can be used in any part of the SQL Command, the most common scenario would be to use a parameter in the WHERE clause of the SQL statement to restrict the records returned from the query. To create a parameter, when in the Add Command to Report dialog, click the Create button. This initiates a dialog that allows the user to specify a name for the parameter, text to use when prompting for the parameter value, a data type, and a default value. After the OK button is clicked, the parameter will appear in the Parameter list. To use this parameter, place the cursor where the parameter should be used in the SQL query, and double-click the parameter name. Figure 3.7 illustrates a simple SQL Command with a parameter.
Figure 3.7 Using a parameter in a SQL Command.
When a SQL Command is created with a parameter, the report developer will be prompted for a parameter value. This works much the same way as parameterized stored procedures in that a parameter will automatically be created in the report that will map to the SQL Command parameter.
Adding SQL Commands to the Repository
You might have noticed that there is an Add to Repository check box on the Add Command to Report dialog. The repository is a new feature of Crystal Reports 9. It will be discussed in detail in a later hour, but a brief description follows.
The repository is a central database that holds various elements of reports. Its purpose is two-fold: reuse and maintenance. When an element is published to the repository, it can then be reused across reports. Then when that element is modified, all reports using that element can be easily updated. In the context of the Data Explorer, the repository is used to store SQL Commands.
Adding a SQL Command to the repository makes a copy of the SQL Command and its associated connection and stores this in the repository database. This is indicated by a special icon next to the connection that resembles a network connection.
A default repository database is set up during installation of Crystal Reports 9 with a name of Crystal Repository. This database is stored as a Microsoft Access database on the local machine. To take advantage of the repository's central storage, it's best to set up a repository database on a central machine in your network.
The SQL Command in the report maintains a link to the SQL Command in the repository. Each time a report is opened, the report developer has the option of updating any repository objects. This is enabled by checking the Update Repository Objects check box within the Open file dialog. Crystal Reports will then check for any updates to that SQL Command, and if any are found, the SQL Command in the report will be updated to reflect those changes. Publishing SQL Commands to the repository provides reuse and maintenance and will provide for a more efficient reporting process. For more information on the repository, see Hour 18, "Working with the Report Component Repository."