>>Paul,
>> I suspect this is a dilemma that many Programmers have. I have posted a thread asking for if anyone has developed a Good report manager class (Thread #153407 Message #153407). Since there has been no responses, I am creating a report manager class that suits my needs. My suggestion for you is to create a separate class that handles the Reports for your framework. The manager can then run in a private data session, you could even make it a ‘dll’ or ‘com’ so that they run separate from the main application and not interfere with the users. When I finish my Report Manager, I will try and post it on UT.
>>Good Luck. Glenn
>>
> I think this is the direction I'm leaning. I've rethought it a little, and I think I'm going to handle running reports through a report class. This class calls any "custom report class" I might have. I haven't decided if I'm going to pass the report object reference to this new class so it can run the standard methods (ie. print, preview, etc) or if I'm going to create a "Custom Report class" that has just standard methods and hook points. Then my Report Manager class can create an object of the Custom Report class, make calls to the standard methods to create the report.
>
> I think the second idea would force me to really standardize my reports and might be the best idea as long as I give myself enough flexibility to handle most situations. I think with a few hooks, this should work OK.
>
>-Paul

Paul -

You may already have the method for which you're looking, but just thought I'd share what I finally ended up doing to pass along some ideas. (By the way, there are some threads on this.) I created a generic report class for all my reports, which relies in part on an external 'reports' table, and in part on the fact that all of my data entry forms allow querying on any field.

I first create a generic report form (Barbara Paltiel gave me the idea of using the same cursor name for all my SQLs, i.e. SELE blah INTO Cursor Rptdata) from my actual data. In the Reports table, I have fields for Report description, the actual .frx name, and a field for the SQL statement (which excludes the WHERE and ORDER by - you'll see why in a minute). I've also included a field for views, but haven't implemented that yet.

The report class allows the user to select their report from a list box, then select the order from the list of fields in another list box, then they can choose the conditions (the WHERE) from another list box, which lets them invoke various data entry classes (relevant to the data used in the SQL statement) where they use pre-existing query forms that allow them to specify they want (e.g. District Judges whose name is "Smith"), and last, I incorporated a slight modification of the print form in the VFP samples, so they can click on Print Preview or Print to see the report.

I use this not only for my reports but for labels as well. I realize this is kind of a Cliff notes summary, and maybe not applicable to your situation, but for what it's worth...

Sylvia