>
>I hope there's no 'Statute of Limitations' on continuing a thread (otherwise this is going to seem like 'The Ghost of Christmas Past';) I ran across your discussion while searching for a solution to my problem: trying to figure out how to allow a user to print different versions of one report, w/o trying to build all these custom report form options. By way of background: I was trying to avoid creating a form which had specific buttons for each different report name and all the attendant 'option boxes'. I wanted instead to create instead a listbox based on a table that contained the variables like "Description, report name, certain options like fields they can order on, select for where clause," etc. Now 20 questions (ok 4):
>
>1) It sounds like your Report.dbf is like what I hoped to do. What kinds of fields does it contain?
>

I don't usually use a report.dbf file but that is just my preference. I have one but don't use it. Anyway, here is the sort of system that I think works well if you do have a report table or if you don't. Here's the scenario:

You have a menu option called reports and under it are a number of different reports that are available in your system. Some of these reports are simple and some are complex. Most of them require parameters of some sort for selecting the data that is report. These parameters can be simple date ranges, selected customers etc. The processing sequence can be defined as such:

[1] select report
[2] enter parameters
[3] choose output destination (printer, viewer, spreadsheet) etc

Option 1 for me is usually a simple do reportxx.prg called from the menu.

the reportxx.prg usually has the same name as the report that will be printed (the .frx) and also the form used for parameters, if it is a unique form. I don't usually use a report.dbf because I find that I tend to build the queries and data from within a prg, based on the parameters. This is especially true if I have to output the data to excel. In one recent case the users wanted the report I generated (the .frx) as an excel spreadsheet. There is no simple method so for the reports that required this option, on their parameter form was an excel option and if this was checked the prg used ole automation to create a the same report using excel (I can actually create reports that look identical - excluding the page breaks!).

In another system the users had options like choosing divisions and the choices were ALL or selected. The default was ALL. If they chose selected they got a mover type form that listed all divisions and they could choose the ones they wanted. One form had some 10 options that all worked like this.

In the prg, if divisions was set to ALL, I ignored divisions in the query. If they were selected, I then created a temporary cursor and added each of the selected divisions to this cursor, I then referenced this cursor in a join condition for my data selection.

In essence, I build the query that selects the data based on my parameters. The actual query that returns the data is always different, and may use different tables based on those parameters. That is why I use the prg, to build the query and the ole automation. Just having a select statement stored in a dbf won't be sufficient. Sometimes it will be, but not always.

Step two was enter the parameters.

This usually happens right at the beginning of the prg. I create an object usually called ox which is a parameter type object. This object has one property which is an array. It is dimensioned to the number of parameters I need. After populating the parameters with defaults I call my form with

do form reportxx.scx WITH ox

One thing I have done is create a two dimensional array so that in the init of the form is code like this:

LPARAMETER ox

thisform.oparm = ox
* get a reference to the object

FOR i = 1 TO ALEN(ox.aparms[], 1)
DO CASE
CASE ox.aparms[i, 1] = 'startdate'
thisform.startdate.value = ox.aparms[i, 2]
ENDCASE
ENDFOR

the above case statement can be filled in with all the parameter names searched for.

The reverse operation is handled in the queryunload so that ox is repopulated.
Just make sure to null out thisform.oparm

When the form returns to the prg (it is a modal form) ox has all of the values entered on the form. Now the prg can do its thing and select all the data. I usually put the data into a cursor called query but it doesn't matter.

Now, once the data is selected I go to step three.

Step three calls my generic 'reporter' form that calls the actual report.

In the prg is code like:

SELECT Query
DO FORM REPORTER WITH 'reportxx.frx'
USE
RETURN

Reporter is a modal form that has options for printer setup (select your printer), preview and print. There is also an excel option that allows output of the data to excel but this is just a dump and not as useful as automation.



Now, if the parameters are generic, I can share the parameter form among reports, but generally I find very few reports use the same parameters. Options like ()ALL or (.) Selected can use generic routines.


I hope this answers most of your questions!!

>2) The Print Form seems like the critical one here because it does the selecting and formating of the data (I assume you mean the SQL that the report form uses). Is this a generic form containing (e.g. listboxes populated from the parameters you pass) and one the user sees so they can make selections as I described above? If not, can you give me an example?

See above.
>
>3) Basic question: How do you pass parameters from one form to another and in particular, what do you pass to your reporting form other than the name of the .Frx itself?

Reporter just gets the name of the FRX but you can add parameters for default values such as output to, number of copies, etc, or these can come from a global object or table that is referenced within the form.

>
>4) I was debating between adding a field to the Report.dbf which contained the SQL for the report (allowing for flexibility to add reports as needed w/o relying on an underlying view), or creating views in my DBC (assuming that if I need a report I might as well create a view). Do you have an opinion about
>this?


I find that when I have to add a report, I also have to add a parameter form and a prg. It may seem simple to just add a new record in a table, but what about the menu? Or is this generated from the table as well? I don't think this method is very flexible because there are always little gotcha's that the user wants that aren't fulfilled by this model. Since you have to add the report It isn't such a big deal to add the parameter form and the prg. Cut and paste helps a lot here. One system I had had an option for a summary or detailed report on the parameter screen and in this case I actually printed from two different FRX's. And in another case, based on the parameters, I had 4 or six different reports that were the final output to the reporter form.

>
>Thanks for any input (I was still working in FPD 2.6 during your original discussion...)
>
>Sylvia
>
>Sylvia