>>Ok, that's the how. What about the "should I?" It seems good in that the report is encapsulated, but loading a whole problem in one of the DE methods (probably AfterOpenTables?) seems wrong somehow. I know there's really not a "wrong" way to do things, but there are better and worse ways. I don't want to start a habit that will be frowned upon buy future bosses.
>>
>>Thanks,
>>
>Hi Michelle,
>
>I don't know how much of what I'm about to write would apply to you, but here are my reasons why I don't use the DE (BTW, there isn't an AfterOpenTables event). My situation is that all reports, except listings (printed copies of the report without calculations), are generated by a query.
>
>1. Since data is validated and sometimes corrected prior to printing the report, using the DE to open the tables is superflous.
>2. Since many reports are identical except for the data grouping, and based on rather complex queries, keeping the query separate facilitates any necessary changes. Rather than having to make changes in multiple reports, and re-distribute each, I simply make the necessary modification in one place, and turn over the application. (Now is there a situation that cries out for object based reports or what?)
>3. This is admittedly a guess, but I don't think that you can do output to multiple devices (file, printer, preview) without having the cursor from which the report is based regenerated (assuming that the cursor would be closed in .Destroy). Otherwise, you have to keep track of it.
>
>That's just my take.


Very good points. I think I'll keep it the way I have it.

Thanks,

-Michelle