![]() |
Reporting with dBASE Plus:
|
Writing Report Generated Data |
The goals for this Session are:
Normally a report reads information from tables in a database. There are, however, times where the developer needs to write information generated from a report. For example, a report might calculate some important totals that need to be saved in a table, or it might be necessary to mark records, with a boolean or date, indicating that they have been printed.
In this session we will look at two reports that write information back to the database.
Locate the report named Writing1.rep in the working folder and open it in the report designer. This is the same report that you modified in Session Three (see Counting1.rep). The report counts the number of Male and Female offspring for each Dam. Now, assume we have a need to save these counts. The number of offspring is an attribute of a Dam, so we will save these summaries in the Dams table. I have already added fields to the table.
For this report we will add an onRender event handler for the FooterBand. As noted before, an onRender event fires after the object is printed. We also need to be aware of when the rowset navigates. Particularly, we want the Master rowset, the one that we are grouping by, to navigate after the groupfooterBand's onRender event fires. Fortunately, it does. Otherwise we would edit the wrong row. So add the following code to the onRender event handler of the footerBand.
function FOOTERBAND_onRender local oRow oRow=this.parent.parent.rowset oRow.beginAppend() oRow.fields["male"].value = this.parent.nMales oRow.fields["female"].value = this.parent.nFemales oRow.save() return
Before this code will work, we need to modify a property of the query. When the report designer adds a query to a report, it sets the "requestLive" property false. This property specifies whether the query should generate a read-only rowset. When set to false, the rowset cannot be edited. Therefore in our report we want to set "requestLive" true so that the Dams1 rowset is editable.
Another caveat of this report is that when you run it from the dBASE IDE, it is rendered to a reportViewer. The reportViewer displays only one page and our new code runs only for those rows that are rendered in that page. In this report only four dams have been rendered.
To see this, run the report but do not scroll through the pages. Instead close it. Then open the Dams.dbf table and browse the Male and Female fields. Data should be seen for only those records that have been rendered.
When a report is outputted to a reportViewer, the only rows that are rendered are those that are visible in the reportViewer. To put it another way, the entire table is not processed, so all the fields in the table are not necessarily updated.
In the next example we will use a conditional test that marks records only when the report is sent to the printer.
Our next report is going to mark those records that have been printed. Billing applications often do this so that there is a record of when a bill was printed.
Open Writing2.rep in the report designer. The report is a listing of dogs and it is filtered for those dogs born in 1975. Assume that we need to mark the filtered record with the date on which they are printed. Perhaps we are sending the dog's owner a letter and want to know when the letter was sent.
The code to mark these records will be entered in the detailBand's onRender event handler. This means that after each detail record prints we will mark the record as sent. Add this event handler to the report and enter the following code:
function DETAILBAND_onRender if this.parent.parent.output = 1 // printer this.parent.rowset.beginEdit() this.parent.rowset.fields['Updated'].value = date() this.parent.rowset.save() endif return
The row pointer is still on the current record after the detailBand renders. Therefore marking the record is easy. We simply put the rowset into edit mode, enter today's date into the field named "Update," and save the row.
The other thing in the above code is that the records are marked only if the report is sent to the printer. Users generally like to preview their reports before printing, and when the user is setting their own filter, they will often need to make more then one attempt before printing. We don't want to mark records until the user "gets it right". This is why the records are marked only when the report is sent to the printer.
The Legal Stuff: This document is part of the dBASE Reporting Tutorial
created by Michael Nuwer. This material is copyright © 2002, by Michael
Nuwer. dBASE, dBASE Plus, dBASE SE, and dB2K are copyrighted, trademarked, etc.,
by dBASE, Inc., the BDE (Borland Database Engine) and BDE Administrator are
copyrighted, trademarked and all that by Borland, International. This document
may not be posted elsewhere without the explicit permission of the author, who
retains all rights to the document.