Report Server | Architecture

Report Server | FAQs

Report Server | Licensing

Report Server | Live Demo

The RAP user interface can be configured to meet the needs of your end users. There are three basic configurations available:

For casual end users, a simple Calculations dialog is accessible from the speedmenu of the new TppVariable component. This dialog provides a place for calculations to be entered and returned via a single Result parameter. The calculation result is then displayed in the variable when the report prints.

In order to configure the user-interface to provide this level of functionality, set the RAPInterface riNotebookTab property to False and the riDialog property to True. The figure below illustrates the Calculations… option available when the end user accesses the speed menu of a variable.

When this option is selected, the Calculation dialog is displayed. The end user can then create code to assign the value of the variable.

For more sophisticated users, RAP can be configured to display as an additional tab in the Report Designer. The new ‘Calc’ tab shows the bands of the report in a tree view, along with the associated variables. The end user can click on the variables and code the calculation in a syntax-sensitive edit window.

In order to configure the user-interface to provide this level of functionality, set the RAPInterface riNotebookTab property to True. When the report designer is displayed, the Calc tab will be visible, and the variables within each band will be listed.

The highest level of functionality is provided by the ‘Event’ view. This capability shows all of the report components in a tree view. When a component is selected, all of the events for the component are displayed. The user can then select an event and code an event handler.

In order to configure the user-interface to provide this level of functionality, set the RAPInterface riNotebookTab property to True and set all of the RAPOptions to True. When the report designer is displayed, the Calc tab will be visible. By right-clicking on the treeview on the left, a speed menu will be displayed that shows the different views of calculations available:

This view shows the variables in each band of the report.

This view shows the report and all of the objects within it. An event handler can be coded for any object.

This view shows the global declarations, functions, procedures, and events.

Screenshots of building a crosstab:

1. Add a crosstab to the report

2. Access the crosstab designer

3. Add a row dimension for State

4. Add column dimension for SaleMonth

5. Add value dimensions for AmountPaid

6. Preview Report

Within the data workspace, you can select data from your database using an SQL query. This functionality is provided via query-based dataviews, which can be visually created using the Query Wizard and visually maintained using the Query Designer. The following series of screenshots shows how to create a simple query-based dataview via the Query Wizard.

1. Select File | New menu option from within the data workspace. The New Dialog will be displayed. Double-click the Query Wizard icon.

2. Select the first table for the query. The customer table has been selected.

3. Select the second table for the query. The order table has been selected and the Join dialog was automatically displayed. The dialog already contains the correct field linking (Customer No.), so all we have to do is click OK.

4. When we return to the query wizard, both tables are shown as selected.

5. Skip the fields page, since we want to select all fields.

6. Skip the calculations page, since this query will not contain calculations.

7. Skip the groups page, since this query will not be grouped.

8. Skip the search criteria page; all records will be selected.

9. Set the order to customer number, then order number.

10. Name the dataview. The datapipeline name is automatically generated when we name the dataview. The next action will be to preview the data.

11. View the data to make sure the correct records have been selected.

12. Close the preview window. The dataview is then created and displayed in the workspace.

From here we could proceed to the design workspace where we could create a new report layout based on this dataview either manually or through the use of the Report Wizard.

The Query Designer is used to modify query-based dataviews. The query designer presents a series of notebook tabs; each tab represents a different part of the query. The last notebook tab in the Query Designer shows the generated SQL and allows the name of the dataview and datapipeline to be changed. The Query Designer is pictured below.

Adding Search Criteria

You can use the Query Designer to add or remove search criteria from your query. Take these steps in order to add search criteria:

1. Click on the Search icon of the dataview to launch the Query Designer.

2. From the list of fields at the top of the search page, double-click on the field for which criteria needs to be entered.

3. Click on the field that has been added to the list of criteria at the bottom and select the operator.

4. Click in the edit box and enter the search criteria value. This criteria will find all company names which begin with the letter ‘S’.

5. Click on the SQL tab to make sure the criteria value is valid.

6. Close the Query Designer and click on the preview icon.

7. Preview the data and make sure that the intended records are selected.

The first step in configuring DADE for your end users involves setting the properties of the DataSettings object of the Designer component.This object contains the following properties:

If you intend to use the Query Wizard and Query Designer, then the SQLType is vital. The following table shows the recommended SQLType for a given database product.

Once you have configured the data settings, you may notice that a Data Settings menu option appears on the File menu of the data workspace when you run your application. This option displays a dialog that allows the end-user to modify the data settings (pictured below). If you do not want the end-user to be able to change these settings, then you can set the AllowDataSettingsChange property of the Designer component to False.

DADE supports a wide spectrum of database engines and data access component sets. ReportBuilder includes DADE plug-ins that support Delphi’s ADO, IBExpress, dbExpress, and BDE components. Advantage, DBISAM, and DOA (Direct Oracle Access) plug-ins are installed with the demos. Additional DADE plug-ins can be downloaded from the companion products page.

The object model below shows the primary classes used to support the plug-in architecture. The abstract ancestor classes are shown in yellow. The classes shown in blue represent the classes required to support a plug-in.

In this diagram, inheritance relationships are indicated by triangles. Where one class is associated with another class, a line is used. If the line terminates in a diamond shape, then it indicates that the class actually forms part of the internal implementation of the component. For instance, the TdaSQL class is part of the implementation of the TdaQueryDataView. The unit in which each class is declared is indicated by the text at the upper left corner of each containing shape.

The following classes represent the heart of DADE. By creating descendants of these classes, native support for any database product that supports SQL can be implemented.

The following classes are used to implement BDE support within DADE. Non-BDE database products that replace the BDE can also be used with these classes.

DADE is a flexible and extensible architecture that enables developers to tailor the functionality delivered to meet the requirements of a particular application. The most common ways in which DADE is extended are as follows:

1. Dataview Templates
Create dataview templates to customize the dataview creation process or to provide datapipeline configurations that cannot be created via the built-in query-based dataview.

2. Support for Non-BDE Database
Create native support for a non-BDE database so that the Query Wizard and Query Designer can be used without the BDE.

3. Ask at Run-Time Support
replace the built-in query-based dataview class with one that provides ‘ask at run-time’ capabilities.

4. New Data Wizard
Create a new data wizard.

A dataview template is a special type of dataview class that has been declared by you, the developer. And while the visual representation of the dataview in the data workspace remains the same as any dataview, the user-interface used to create and modify the dataview is totally dependant on what you want to provide to end-users. Dataview templates can be used for anything from creating predefined relations between a set of tables to integrating a full-blown query builder. In this section, we will show how you can create a dataview template. But before we do, let’s take a look at what the end-user will see when he uses a dataview template.

When dataview templates are registered with DADE, an additional tab is added to the New dialog. The figure below illustrates what we would see by accessing the File | New menu option within the data workspace:

Here we can see that six different dataview templates have been registered. After double-clicking on the ‘Order’ template, we see the following screen:

This is a custom dialog created by the developer of the Order dataview template. It allows the end-user to enter simple search and sort criteria. Once we’ve done this and click OK, the completed dataview will be displayed:

As you can see in the data pipeline list of this dataview, this template has declared relationships between the customer, order, and order items tables. Each table is independent and has its own data pipeline. By clicking on the Design tab and accessing the Report | Data menu option, we can see how this dataview has assigned the data pipelines to the report:

The customer data pipeline is assigned as the master and the orders data pipeline is assigned to the detail band. The items data pipeline is available, and we could create a subreport and assign it to this datapipeline. This sort of data pipeline configuration is not available from query-based type dataviews, so this is probably one of the reasons why the developer chose to create this dataview template.

This dataview template is implemented as an SQL query on the customer table with nested detail tables on the order and items tables. Some of the fields from the order detail table are actually supplied from the employee table, which is configured as a lookup table:

A completed and working version of the order dataview template is available in the Demos\EndUser\2. Custom DataView Templates\ directory within the main ReportBuilder directory.

DADE is built upon the concept of the dataview. A dataview is responsible for creating the data access objects required to connect a report to data. A dataview must contain at least one datapipeline. A typical dataview will contain one or more datapipelines, datasources, and datasets. Dataviews are created and maintained visually in the data workspace of the report designer. By implementing new descendants of several classes within DADE, we can integrate a non-BDE database into DADE so that the visual tools provided in the data workspace (i.e. the Query Wizard, Query Designer and custom dataview user-interfaces) can be used with that database.

In the course of normal operation, the Query Wizard and Query Designer require certain information from the database, such as a list of tables from which data can selected, or a list of fields for a given table. These visual tools never directly reference any database objects in obtaining this information, but instead rely on functionality provided by the dataview. This architecture enables these tools to be used without the BDE.

As an example, we have created a dataview descendant that can be used with ODBC98.

ODBC98 is set of native Delphi data access components that provide direct access to ODBC databases without the BDE. The components for the most part mimic the BDE- based components found in Delphi (Session, Database, Table, Query, StoredProc, etc.). ReportBuilder is designed to access TDataSet descendants via the DBPipeline component. Therefore, it can work with ODBC98 seamlessly right out the box. ReportBuilder Pro, however, contains the Query Wizard and Query Designer, which are designed to work with a special dataview class: TdaQueryDataView. Therefore, we must create a descendant of this class in order to integrate ODBC98 with ReportBuilder Pro.

Implementing a QueryDataView descendant requires us to define the following set of classes:

If you have ODBC98, you can see these classes in action by installing the ODBC98 demo provided in the ReportBuilder Pro EndUser\Demos directory. Complete directions for installing these classes is provided in this directory.

Ask At Run-Time support refers to the common task of allowing the end-user to specify parameter values that can be used to limit the scope of a report.  As an example, for an invoice report, the end-user might specify a company name and date range.

ReportBuilder’s AutoSearch feature offers a RAD solution to the drudgery of adding ask-at-runtime support to your reports.  ReportBuilder’s Query Designers can be used to designate search criteria as AutoSearch.  Thereafter, any time the report is executed, ReportBuilder will display an ask-at-runtime dialog and use the parameter values entered by the end-user to dynamically generate the SQL Where clause for the report.

The following screen shot shows an example of an ask at run-time dialog generated and displayed by ReportBuilder.

The default AutoSearch dialog can be replaced by a customized version that you create and register with ReportBuilder. A demo of this technique is provided in the Demos\EndUser\5. AutoSearch \4. Custom AutoSearch Dialog\ directory.

The Report Explorer component allows you to deploy a Windows Explorer interface that your end-users can use to organize their reports. The Report Explorer handles all operations via datapipelines; therefore, the folder structure and all of items within it can be saved to database tables. This interface presents a minimal learning curve as most users are familiar with the operation of the Explorer. The Report Explorer user-interface is pictured below:

The action that each button on the Report Explorer toolbar performs is described below:

The data dictionary is a non-visual component designed to provide the data workspace with the capability to replace the table names and field names retrieved from the database with more readable aliases that you provide. The most commonly used properties of the data dictionary are described below:

The data model for the database tables underlying the data dictionary is shown below:

The TableName is the key field of the table. The TableName and FieldName are the key fields of the field table. The Selectable field determines whether the field can be selected within the Query Wizard and Query Designer. The Searchable field determines whether the field can be used in search criteria. The Sortable field determines whether the field can be used to order the data.

Once the data dictionary tables have been created and populated, they can be assigned to a standard Delphi TTable or TQuery component, which can then be assigned to a data pipeline via a TDataSource. The pipelines are then assigned to the TablePipeline and FieldPipeline properties of the data dictionary. The diagram below shows a fully configured data dictionary component. The data dictionary component is assigned to the data workspace via the DataDictionary property of the designer component.

The Data Dictionary Builder is an editor for the DataDictionary component. It is designed to generate and maintain the DataDictionary information used by the Data workspace. To access the DataDictionary Builder, configure theDataDictionary.BuilderSettings to connect to your database and then double-click on the DataDictionary component.

The following options are provided:

In order to create the most sophisticated and complete end-user reporting solution possible using ReportBuilder, we need to connect and configure all of the components available in ReportBuilder Professional.

The screenshot below shows the configuration of a full-featured end-user reporting solution (the colored shapes and labels have been added for informational purposes only).

A completed version of this solution is available in the ..RBuilder\Demos\EndUser\1. Report Explorer directory. Step-by-step instructions for creating this application are provided in the‘Building an End-User Reporting Application’tutorial of the Developer’s Guide.

ReportBuilder Professional and Enterprise Editions include the ability to build end-user reporting solutions that are royalty-free. The End-user reporting solution must be a part of a larger application and access a single database. For example, you cannot build a general purpose query or reporting tool and distribute that royalty-free. The license prohibits this type of solution.

ReportBuilder Server Edition currently includes a single developer license for ReportBuilder Enterprise and a single developer license to ReportBuilder Server. Also included is a Server Deployment License for a single CPU. This enables you to install a report server solution to a single CPU machine. Additional Server Deployment licenses are US $299.00 per CPU. Thus to deploy a server solution to a dual processor machine requires two deployment licenses. A report server can support as many clients as the hardware will allow. In summary, the licensing is per server CPU, not per client seat.

In traditional banded-style report writers, reports that can be printed from a single source of data are quite easy to create. But if the content of the report consists of information from several different sources of data, the choices become quite limited. One option is to use SQL to join the data together into one’virtual table’, and then build the report based on this table. If many tables are involved, the performance of this approach can be prohibitive.Delphi provides an alternative to this approach by allowing linkages to be established between data access objects. Within ReportBuilder we can use free-form subreports to take advantage of the many configurations these data access objects make possible.

A single data source can be connected directly to the report via the DataPipeline property. When printed, the report will generate one detail band for each record provided by the data source.

Here we have three sources of data with no linkages between them. In this report we want to print all of the customers, then all of the products, and then all of the vendors. The report needs to fit together like a book, with each data source providing a ‘chapter’. Here we use the main report to launch a subreports for each of the data sources. The subreports would be set with a PrintBehavior of section, which means that each subreport would start a new page, generate a set of pages as necessary to traverse all of the data of the data source and then return control to the main report. The main report is not connected to any data source, so we would manually stop the report generation process by coding an event handler in the detail band AfterPrint event. This event handler would call theReport.DataTraversalCompleted procedure, which would stop the report generation process after all of the subreports have completed printing.

In this scenario, the master data is connected to the detail data via a field or set of fields. It is assumed that this connection results in multiple detail records being selected for each individual master record. The master data source is assigned to the report, and the detail data source is assigned to the detail band of the report. The report steps through each of the master records and generates one detail band for each record in the detail data source. If there are no corresponding detail records for a given master record, the report generates a blank detail band.

Here we have the master data source containing a list of customers. Each customer has multiple orders; each order has multiple products, and each product has multiple potential vendors. This configuration is called ‘nested’ because each set of records is selected based on the linkage established with the previous data source.

The first two data sources can be handled as in the standard Master/Detailarrangement. The customer data source is assigned to the report, and the order data source is assigned to the detail band. The next two data sources can be handled by a subreport. A subreport has all of the capabilities of a regular report – the only difference is that it can be placed within the band of another report. In this case, we place the subreport in the detail band of the main report. It will then print once for each order record. Within the subreport, we assign the report to the part data source and the detail band to the vendor data source.

By configuring the report in this manner, the following information will be printed: all customers, all orders for each customer, all parts for each order, and all vendors for each part.

Here we have the order table. Each order has many order items. For each order there is also a group of vendors that can supply the products for that order. Both of these data sources are linked to the master data source, as opposed to being nested within one another; therefore, the data sources are ‘independent’. This type of data can be handled by placing two subreports in the detail band. The first subreport can be linked to the order item data source, and the second subreport can be linked to the vendor data source. In order to print the vendor data after the order item data, we would link the vendor subreport to the order item subreport via the ShiftRelativeTo property.

Form Emulation is the process of taking a paper-based or electronic form and rendering a likeness of it. The likeness may include formatting of the form itself, or may only contain the data which will ‘fill-out’ the form. There are two basic issues that a form emulation solution must resolve:

1. How will the formatting of the form be generated?

2. How will the data which ‘fills-out’ the form be generated?

The first issue is resolved by using either a page-sized band within the report or by utilizing a page style. A page style can be designed just like a band, but generate as a background to the bands of the report.

The second issue is resolved by using either simple data-aware components or by using more complex region or subreport components.

In ReportBuilder, there are several approaches that achieve form emulation. These approaches are discussed in detail in this section.

1. Expand the detail band to the printable height of the page, hide the header and footer band, and place all form formatting and data-aware controls in the detail band. This approach yields one form per record. The following diagram shows an entire form in the detail band.

2. Add a page style to the report. Place all formatting for the form in the page style. Layout the data-aware controls as you would when building a normal report. This approach yields a variable number of records per form, depending on the height of the bands. In this approach, the detail band is used to ‘fill-out’ the form. The following diagram shows how a detail band can ‘fill-out’ a page style.

3. Expand the detail band to the printable height of the page.  Hide the header and footer band, and place all form formatting in the detail band. Place child-type subreports in different areas of the form where a table or particular source of data is needed to fill out that part of the form. Place data-aware components in areas of the form where the master datapipeline supplies the data. This action yields the most flexible and powerful form emulation solution, but is only needed when multiple data sources are used. The following diagram shows subreports filling out a form in the detail band.

The form itself may be too complex to recreate using report components. In this case it is recommended that you scan the form and convert it to a windows metafile. You can then place the windows metafile in the report as either a ‘background’ for the detail band or in the page style, where it will function naturally as a background for the report.

When you have a form in a WMF image, the end-user gets an excellent print preview capability. If you are printing on pre-printed forms, you can set the visible property to false when the report is sent to the printer. In this way you can provide a filled-out form in the print preview window, but only the text necessary to ‘fill-out’ the form is actually sent to the printer.

All of the approaches discussed in the single page form topic are applicable to the multi-page forms. The additional problem of organizing single-page forms into sets of multi-page forms can be resolved using section style subreports. When Section-style subreports are rendered, they generate a new page within the parent report, continue generating pages until all data has been traversed (or they are stopped manually through a procedure call to the report engine), and then return control to the parent report. One special behavior of section-type subreports is that the parent report generates no pages when the section is placed in a dynamic-height detail band. In this case, the main report is used as a launching pad for one to many sections. Since each section is a full-fledged report in its own right, all of the single page form approaches can apply to each section, thus creating a multi-page form solution.

The diagram below shows three section-type subreports in the detail band of the main report. The main report is assigned to a data pipeline, so the detail band will print once for each record. The subreports contain data-aware controls that point at this data pipeline. After the detail band of the subreports prints, the DataTraversalComplete method of the report is called, manually stopping the report. This report provides three pages of content for each record, and each page has its own unique format.

The various toolbars accessible from the design workspace are documented in this section. The toolbars are dockable and follow the Office97 interface style. The Toolbars are accessible from the View | Toolbars menu option of the Report Designer or by right-clicking on the docking area at the top of the Report Designer.

To access this tool window, select the View | Toolbars | Report Tree menu option from the Report Designer main menu. This tool window is dockable only on the left and right sides of the Report Designer. It can be used to organize components within each band. Components selected in the Report Tree are selected in the report layout. The upper portion of the Report Tree shows the main report object and any subreports nested within it. This feature can be helpful for organizing your subreports.

To access this tool window, select the View | Toolbars | Data Tree menu option from the Report Designer main menu. This tool window is dockable only on the left and right sides of the Report Designer. It can be used to create components within any band. Simply select a set of fields and drag the selection into the band. A set of corresponding data-aware components will be created.

ReportBuilder contains a Report Wizard that allows you to quickly create an entire report layout. This is great for generating an entire report, but what if you need to create only a portion of a complex report? Drag and drop functionality is an ideal solution for this problem because it allows you to create a set of components within the context of an existing report layout.

In ReportBuilder, drag and drop support is provided via the Data Tree (pictured below).

The Data Tree has two tabs. In the top tree view, the ‘Data’ tab contains a list of data pipelines to which the report has access. In the bottom list view, all of the fields for the currently selected data pipeline are displayed. Fields can be selected from the bottom list view and dragged to any part of the report layout. The data-aware component that is appropriate for the given field will then be created along with a label and border.

The second tab of the Data Tree is entitled ‘Layout’. This tab allows you to control the behavior of drag-and-drop. By default, a label and border are created for each data-aware component. You can turn the label off, the border off, control the color of the label or border, and control the font of the label and data-aware component from this tab. Once you’ve set the drag-and-drop behavior, it will be retained for future design sessions.

The following screen shots step through the creation of a simple report via theReport Wizard.

1. Select the fields.

2. Skip the groups page.

3. Select the layout.

4. Select the style.

5. Select Design or Preview and Finish.

6. Report as it appears in the Preview & Design workspace.

The Report Wizard is one of the many parts of ReportBuilder that reflects a level of professionalism and attention to detail found in no other reporting product. If you or your end-users have utilized standard Windows wizards in other products, then you will be able to quickly recognize and use the ReportBuilder Report Wizard.The Report Wizard can be accessed via the File | New menu option of the report designer. A series of screens are presented, each requesting information about the report. When the last page is reached, either a preview or design option can be selected. When the ‘Finish’ button is clicked, it ca uses a report to be created and displayed as requested.

ReportBuilder augments this data access model by adding another component: the data pipeline. There are several different types of data pipelines, but for purposes of accessing database data, a DBPipeline component can be used. The following screen shows a DBPipeline retrieving the same field value.

BDE stands for Borland Database Engine. The Delphi development environment utilizes the BDE to access data in desktop database files (such as Paradox or Access) and in client-server databases (such as Oracle and Sybase).One of the reasons Delphi has been so successful is the wide range

of datasets that can be accessed via the BDE. ReportBuilder leverages this powerful solution with standard support for the BDE. In Delphi, data access via the BDE can be accomplished using a TTable or TQuery component. A TDataSource component is then connected to the table or query. A data-aware component can then be connected to the datasource. The following screen-shot shows a field value being retrieved into a data-aware memo component.

The value is displayed in a ReportBuilder data-aware memo component. You may notice that only the first line of the memo is shown in the ReportBuilder Report Designer. This is due to the fact that when the report generates, the memo component will recalculate the height based on the text it contains. Therefore, there is no reason to specify the height of the memo in the report layout, as it will automatically resize on the printed page.

Reports can be printed directly from text files without using a database product. This functionality is provided via the TextPipeline component. The following formats are supported:

•  Comma-delimited
•  Tab-delimited
•  Fixed-Length records
•  Custom delimited (where you specify the delimiter)

The TextPipeline component is essentially a simple data retrieval engine that enables you to access data in text files in the same manner as data stored in a database table. You can even define master/detail relationships between data in two text files. The TextPipeline contains a Field Editor that is used to define the data fields for the text file. Once the data fields have been defined, you can access the Report Designer and assign those fields to ReportBuilder’s data aware components.Each of the data pipelines in ReportBuilder has a Field Editor that is accessible by double-clicking on the pipeline component at design-time. The TextPipeline’s Field Editor is pictured below. Notice that the View Data button has been activated to display the contents of the text file. This feature is useful when defining the fields for the text file.

Data pipelines present a structured set of data to a report. This structure takes the form of records and fields. The report engine expects operations like open, first, next, and last to provide a certain response from the data pipeline. The data-aware components within the report expect field values to be retrievable by simply passing a field name to the data pipeline. In the DBPipeline component, this functionality is implemented by calling the methods of a TDataSet object. However, this is not the only way a data pipeline can provide the necessary data access functionality to a report. The JITPipeline (JIT stands for Just In Time) triggers events to accomplish the same results as the DBPipeline. That is, the JITPipeline provides a set of events that, when coded properly, allow reports to print from any source of data referenced by the event handlers. The following diagram shows a JITPipeline that is assigned to event handlers referencing a standard Delphi string grid. In the report, data-aware components are created just as they would be for any other database report, by assigning field names from the JITPipeline to the data-aware controls in the report. This results in a clean, maintainable implementation. If you later decide to provide data to the report via a text file or database table, you can simply swap out the JITPipeline with a new pipeline of the correct type.

For more specifics on the JITPipeline, see the Developer’s Guide or the Online Help.

If you have a considerable amount of data in a proprietary format and many reports need to be created based on this data, the highest level of maintainability and ease of use will be provided by a custom data pipeline component. This type of component can be created by descending from the TppCustomDataPipeline class and implementing the necessary methods. The end-result of such an effort will be a new data pipeline component that can be installed into the Delphi IDE and used on the same basis as the other data pipelines that are provided with ReportBuilder.

An object model of the ReportBuilder DataPipeline classes is shown below.

The most high-profile and often-used form of report output is contained in the Print Preview form. The Print Preview form is launched automatically when the Print method of report component is called (and the DeviceType property has been set to ‘Screen’). The Print Preview form is pictured below.

The user can preview any page of the report from this form, zoom the page to different levels, and print the report to the printer.

While the Print Preview form provided with ReportBuilder looks and performs like a truly professional user-interface should, you may want to customize it to emulate the look and feel of the rest of your application. This customizing can be done by creating a special form that descends from the CustomPreviewer class and registering it as the ‘official’ print preview form. This process is fully described in the tutorials of the Developer’s Guide.

ReportBuilder contains a host of properties that allow you to control various aspects of the print job.

These properties are contained in the PrinterSetup property of the Report object and can be configured via the Object Inspector or the File | Page Setup dialog of the report designer.

Because all ReportBuilder reports contain a PrinterSetup object, it is possible to use section-type subreports to achieve some fairly incredible levels of print behavior customization. For example, different pages of a report can print from different bins of the same printer or print to different printers entirely. Some of these features are showcased in the printer setting demos provided with ReportBuilder (check demos 121-124).

The TextFile device in ReportBuilder converts report output into an ASCII text file. The intent of this device is to create structured data that can be imported into another application, such as a spreadsheet. The following text file formats are supported:

•  comma-delimited
•  tab-delimited
•  fixed length records
•  custom-delimited

Because report output is essentially free-form and can contain many non-textual components, ReportBuilder provides a way for you to tightly control the format of the text file generated via this device. This control is provided by the Print to File Setup dialog(accessible from the File | Print to File Setupmenu option of the report designer). This dialog is pictured below.

This dialog allows you to set the default file name, select the file format, and specify the textual components that will be saved to the file and the order they will be saved. When utilizing the TextFile device, it is mandatory that these settings are completed. If no components have been selected, then a blank text file will result.

1. Print directly to ASCII text file.

Once a report has been configured for ASCII text file output, the following code will generate the report directly to the file:

uses

ppTypes;

ppReport1.ShowPrintDialog := False;

ppReport1.DeviceType := dtTextFile;

ppReport1.Print;

2. Allow the end-user to print to ASCII text file.

The following code will give the end-user the option of printing to text when the print method is called:

uses

ppTypes;

ppReport1.AllowPrintToFile := True;

ppReport1.DeviceType := dtPrinter;

ppReport1.ShowPrintDialog := True;

ppReport1.Print;

The report component has an OnSaveText event that fires each time a textual component is saved to the text file. This event can be used to customize the output generated to the text file. An example of what can be achieved via this event is provided in demo 106 (..\RBuilder\Demos\Reports\dm0106.pas).

By utilizing the highly extensible device architecture of ReportBuilder, it is possible to create your own device class descendants for converting the native output ofReportBuilder into any file format. Some developers have already done just that, and are offering device classes for some of the most popular file formats. These additional devices integrate seamlessly into ReportBuilder.

You can control whether end users can Archive or Print to any of the supported file formats using the following properties of the Report object:

•  AllowPrintToArchive
• AllowPrintToFile

Setting AllowPrintToArchive to True will enable end users to archive reports. You would then need to provide a user-interface for previewing and printing the archived files using the ArchiveReader component. For an example of how to use theArchiveReader, see demo 151 (..\RBuilder\Demos\Reports\dm0151.pas).

Setting AllowPrintToFile to True will enable end users to print to the any of the available file formats. You can control which file formats are available to end users via the device class registration procedures. For example, the following code would remove the ReportTextFileDevice from the list of available file formats:

uses

ppDevice, ppFilDev;

ppUnRegisterDevice(TppReportTextFileDevice);

In order to set the AllowPrintToArchive and AllowPrintToFile properties within the context of an end-user application, the OnNew and OnLoad events of theReport.Template object should be used to set the default properties of the report. For example, in the End-User demo application, you would add the following code to the main form:

procedure TmyEndUserSolution.FormCreate(Sender: TObject);

begin

{assign event-handler to template events}

ppReport1.Template.OnNew := ReportTemplateEvent;

ppReport1.Template.OnLoadEnd := ReportTemplateEvent;

{remove the report text file device }

ppUnRegisterDevice(TppReportTextFileDevice);

end;

procedure TmyEndUserSolution.ReportTemplateEvent(Sender: TObject);

begin

{set default report properties}

ppReport1.AllowPrintToArchive := True;

ppReport1.AllowPrintToFile := True;

end;

The end-user reporting solution in ReportBuilder Professional is comprised of three primary components that can be configured at Delphi design-time. Each component contains properties pertaining to data access.

1. Report Designer

The Designer’s DataSettings object is used to specify the connectivity parameters for the query wizard and query designer tools. In a typical end-user reporting solution, the end users will be creating and modifying reports that access data residing in a departmental or corporate database.

2. Report Explorer

The Report Explorer’s Folder and Item objects are used to specify connectivity information for the folder and item database tables. These tables are used to store the folders, reports, and dataviews created by the end-user. Depending upon the specific requirements of the application, the folder and item database tables may reside in a local database on each user’s workstation, or they may reside in the database server.

3. Data Dictionary

The DataDictionary’s Table and Field objects are used to specify connectivity information for the table and field database tables that are used to provide user-friendly table and field alias information to end users. The table and field database tables may reside in a local database on each user’s workstation, or they may reside in the database server.

In this scenario, each user has a local copy of the end-user tables that are used as a personal database for storing their reports. For example, suppose the corporate database resides on an Oracle database server and you decide to deploy the end-user tables locally using SQLAnywhere. To implement this strategy, you would configure theTppDesigner.DataSettings to specify the connectivity parameters for the Oracle database server. The Report Explorer tables would reside in the local SQLAnyWhere database, and the Data Dictionary tables could reside in either place, depending upon your preference.

In this scenario, reports created by end users reside in a multi-user database that is shared. For example, if the corporate database resides on an Oracle database server, the end-user tables would also reside on the Oracle server.

ReportBuilder can be deployed as part of your executable. Simply include the correct path to the compiled units (.dcu files) of ReportBuilder in your Delphi Library Path. For example:

‘c:\program files\borland\bds\3.0\rbuilder\lib’

The ‘lib’ directory contains the compiled units of ReportBuilder. When you compile your application, necessary dcu files from this directory will be linked into the resulting executable file. Executable files created this way are stand-alone in that they can be distributed successfully without any supporting files.

Applications containing ReportBuilder will not compile correctly if the library path is not configured properly. If there are directories in the Library path pointing at old versions of ReportBuilder or at the Source directory of ReportBuilder, problems will result.

In order to access your Library Path in Delphi, select Tools | Environment Options from the Delphi main menu. The Environment Options dialog will be displayed. Click the Library tab. The Library Path is the first item. Click the dialog button to the left of the library path edit box. The directories that make up your library path will be displayed.

You can optimize the size of your executable by compiling your project with packages. To compile with packages, access the Project Options dialog, select the‘Packages’ tab, and click on the ‘Build with Packages’ check box. The list of package names that appears to the left of this check box should include the followingReportBuilder run-time packages:

A typical package list for a project containing a ReportBuilder report is as follows:

Vcl90;Vclx90;Vcldb90;vcldbx90;VclSmp90;rbDBDE99;rbRCL99;rbDB99; rbTDBC99;rbUSER99;tee90;teeUI90;teedb90

These packages break down as follows:

All of these packages should be distributed with your executable file in order for it to run properly. These packages are usually installed into the Windows\System directory of the target computer, since this is where most DLLs reside.

ReportBuilder includes support for 11 built-in languages. The strings for each language reside in separate resource files. These files are located in the..RBuilder\Languages directory, under a subdirectory named for the given language. Three letter codes are used to differentiate the language DLLs that are installed in the Windows\System directory.

The following components appear on the Standard Component Palette of the Report Designer when you install ReportBuilder:

The following components appear on the Data Component Palette of the Report Designer when you install ReportBuilder:

The following components appear on the Advanced Component Palette of the Report Designer when you install ReportBuilder: