>>>>>>>How wuold I go about basing a report on a parameterized view? Is it possible without using a public variable? ie- can I pass the paramater by value to the report?
>>>>>>
>>>>>>It's actually local variable:
>>>>>>
>>>>>>***cmdRunreport click event
>>>>>>local nViewparameter
>>>>>>nViewparameter=....
>>>>>>Select view1
>>>>>>=requery()
>>>>>>Report Form ....
>>>>>
>>>>>Erik,
>>>>>
>>>>>Can I assume that you want this to be a 'standalone report' with the view in the report's DE? If so, what if you put code in the DE's Init to prompt the user for the parameter(s) and then add the view to the DE using the parameters you collected..
>>>>>
>>>>>HTH
>>>>
>>>>No can do. Tables in question use surrogate keys that the user would have no idea about.
>>>
>>>In that case, use Ed's idea with the Default DS
>>
>>I could use the default datasession on the report, but the form that it prints from uses a private datasession, and must stay that way, because the program allows the user to open multiple instances of the for... what I was hoping for was a way to pass the parameter to the report. I suppose that I could save my view with a different name and remove the parameter in the view itself, and then REPORT FORM for parameter = value. This would quickly make the number of my views explode, however, because I have a lot of forms that display the data from a view in which I want to put a print button to allow the user to print the data on the screen in a formatted report.
>
>
>Here is the method I use for printing reports and see if it can fit your situation. I have a standard reporting form that allows the user to do a print preview, print hardcopy, print to file or change printer setup. All of my reports funnel through this form. I pass to this form the name of the report and any other necessary parameters. The key thing is, the form assumes that all the data is ready and prepared for printing. I do NOT use the data environment of the reports. Now, the report does reference fields and must assume that the appropriate tables are available but the report does open anything. This is the function of my print routine, before calling my report form. This form is modal so if the user has decided to print, he must finish this choice before moving on to other forms. Because it is modal, it uses the default data session, which is the session of the form that called it.
>
>Now, if your print button provides another screen to accept some parameters, this is the form that should then select and format the data before passing control to the final reporting form. In this way I provide a consistent and standard interface for printing.
>
>Bob

Bob (et al.) -

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?

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?

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?

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?

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

Sylvia

Sylvia