Without 'going the whole nine yards', it can be reasonably easy.
For many applications, there are a limited number of report types which are used by the majority of users. If you analyse the business process, you can generally identify most of them. Take some 'common' report type desired by many groups using the db. Lay out a report which has the elements desired. Base it on a query. Paraameterize the report to provide the flexability which accomodates the majority o fthe uses needs. Set these parameters from a form, designed to make the paramter selection easy and fail proof.
Look at a SMALL example. From a call center db. Every department needs to know about the calls directrd in their department. They need to know this for various intervals(Day, Week, two Week, Month, Quarter, and Year). So, on the form there is an option group for the dept. and two text boxes and an option group for the dates. the Dept is (in the SIMPLISTIC sense) simply the list of departments. Selecting the Dept, provides the parameter fo the query. For the dates, the user needs some more hand holding. The option Group would have the options noted above (or your replacement list) AND a custom button. Use of any button - EXCEPT the custome would populate the two text boxes with the appropiate start and end dates for the interval selected. Continue this exercise to a reasonable conclusion, and you end up with 80 to 90% of the reports for the app, using maybe 20% of the queries and reports of a full set of custom reports. Some bells and whistles make you a 'hero'.
MichaelRed
mred@att.net
There is never time to do it right but there is always time to do it over