>>>We want to have a single report form handle a variety of similar reports. They are all somewhat related in functionality, but differ as to the tables. The table structures are also similar, but not always exactly the same. Any ideas on how to handle this best?
>>
>>I created a generic report handler many years ago, which has saved me many hours later. It takes two parameters, namely the name of the FRX and the output (screen, printer, email, file). The second parameter is analyzed by the program,. If it's empty, output goes to the screen. If it's a legal URL, output goes to a file and is converted into the format which matches the file extension. If the URL does not have any extension, it must be a printer, and is sent to it. The same happens if the second parameter is a single word, like LPT1 or Myprinter. And last, if it's a legal email address, it's sent to this address as a PDF attachment. If all fails, the program reports -1 to indicate a failure.
>>
>>Needless to say, the report takes its data from the currently selected table or cursor.
>
>I'm not sure that is what I was looking for. I'm looking for ideas on how to handle the different, but similar, data prior to printing the report. Your stuff seems interesting, but maybe I missed something as it doesn't seem to address what I asked.

First of all, I don't do much reporting. But one lesson I learnt many years ago was to do all the data munching first, and not in the report itself. I know this is not usable in all scenarios, but for me it has always been the best way. If more than one data source/table are involved, I use SQL and/or cursors to create one single cursor wihich contains all the data for the report engine. This makes me able to use browse to see pretty much how the resulting report will look like.