>>
>>
>>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
>
>DUH! I'm an idiot! I do the same thing, and it never occurred to me that this would help!
>
>Erik, not only do I do this, I mix it up. Some of my reports are very standalone and never change so I do use the DE. Some are in a generic format where the paramters and titles change and I create the public variable on my print form and release it in the release event. I have a list of #DEFINES in my main header which list the title and cooresponding frx. I use these to populate arrays throughout the system. (In the past, I've alos done this with a reports table) For example report #1, 2 and 3 are....
>#DEFINE R_NAME1 "Completed Notification"
>#DEFINE R_FRX1 "problem"
>#DEFINE R_NAME2 "Problem Notification"
>#DEFINE R_FRX2 "problem"
>#DEFINE R_NAME3 "Status Report"
>#DEFINE R_FRX3 "status"
>
>3 reports...2 frxs.
>
>Also, if you use the reports.dbf method, you can use a memo field to put in code that should run prior to running a report. The code can be run with macro substitution.
>
>HTH
>
>(I LOVE BRAINSTORMING)

DAMN!! Now that's a Solution!!! I love this forum. I can't say how much I appreciate you guys taking this dilemma on. I will probably asking how to work out some of the details of this method in the coming days... stay tuned.

Erik Moore