Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations MikeeOK on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Ad-Hoc Reports
- Thread starter Tejanorey
- Start date
- Thread starter
- #2
- Thread starter
- #3
Still open for suggestions. I have created a database that has all kinds of information but the problem is that I need some guidance to create a form that a user can choose what ever options they want on the form and then with one click of a command button it will generate a report. I would greatly appreciate any type of advice or guidance. Thank you. Tejanorey
"Do not attack the First Marine Division. Leave the yellowlegs alone. Strike the American Army."
- Orders given to Communist troops in the Korean War; shortly afterward, the Marines were ordered to not wear their khaki leggings to keep the enemy from immediately fleeing
"Do not attack the First Marine Division. Leave the yellowlegs alone. Strike the American Army."
- Orders given to Communist troops in the Korean War; shortly afterward, the Marines were ordered to not wear their khaki leggings to keep the enemy from immediately fleeing
MichaelRed
Programmer
The prospect of creating a truly "ad-hoc" report in Ms. A. is a larger task than usually undertaken on a pro-bono basis. On would be faced with a large number of issues:
Generating the recordset would include selection (or perhaps generation and / instantiation) of the source recordset(s), including potential calculated fields.
Where multiple sources were involved, specifying the relationship(s) ([Joins | [Inner | left | Right]] ... ]
Field Selection (possible calculated fields) and formatting.
Selection of sort and group fields and options (including the group headers and footers)
Selection of included fields.
Placement of available fields on the proper report section.
Ordering (placement) of selected fields within the section, as well as setting the attributes (Size, Font Color, Bold, Left, Top, Width, Height, Visible, Format ... )
Generaton of label controls and their captions (for each included control)
Generation of caculated controls (running sum over ([Group | all])
Print set up (Portriat | lanscape], Margin settings, Printer selection ...
And this is just to mention the more obvious (common?) exercises.
_______________________________________________________
_______________________________________________________
_______________________________________________________
Having said that, it is often possible to offer users choices of various options for reporting purposes. An approach to this would be to analyse the report requests to determine the various 'supersets' of recordsets necessary to support the reports and generate them (the queries and reports) statically (saved queries) with the various optional selections as parameters within the queries.
I have used a tab control to then offer the various canned reports, with the reports being listed on the first page, and the options listed on subsquent pages, with the defaults pre-set into the option selection controls. A final page of the tab control just instantiates the report.
Using this approach, I was able to remove ~~ 2/3 of the reports from a system I was hired to 'fix' while improving the overall reporting capabilities -AND reduced the use of the 'whine and cpomplain' option from the users.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
Generating the recordset would include selection (or perhaps generation and / instantiation) of the source recordset(s), including potential calculated fields.
Where multiple sources were involved, specifying the relationship(s) ([Joins | [Inner | left | Right]] ... ]
Field Selection (possible calculated fields) and formatting.
Selection of sort and group fields and options (including the group headers and footers)
Selection of included fields.
Placement of available fields on the proper report section.
Ordering (placement) of selected fields within the section, as well as setting the attributes (Size, Font Color, Bold, Left, Top, Width, Height, Visible, Format ... )
Generaton of label controls and their captions (for each included control)
Generation of caculated controls (running sum over ([Group | all])
Print set up (Portriat | lanscape], Margin settings, Printer selection ...
And this is just to mention the more obvious (common?) exercises.
_______________________________________________________
_______________________________________________________
_______________________________________________________
Having said that, it is often possible to offer users choices of various options for reporting purposes. An approach to this would be to analyse the report requests to determine the various 'supersets' of recordsets necessary to support the reports and generate them (the queries and reports) statically (saved queries) with the various optional selections as parameters within the queries.
I have used a tab control to then offer the various canned reports, with the reports being listed on the first page, and the options listed on subsquent pages, with the defaults pre-set into the option selection controls. A final page of the tab control just instantiates the report.
Using this approach, I was able to remove ~~ 2/3 of the reports from a system I was hired to 'fix' while improving the overall reporting capabilities -AND reduced the use of the 'whine and cpomplain' option from the users.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
- Status
Similar threads
- Locked
- Question
