Launching Reports

[purchaandr]

Hey there guys,

I have been looking all through the internet and on the forums and have not been able to find a good solution for launching reports from a form. I was wondering if anyone had any guidance on what to do?

So far I have a Listbox Where I have typed in the names of the reports manually and have an on click eventprocedure to look at what report has been clicked and to launch it from there. Is this a good way or is there a way better way to do this?


Thank again,

Andrew

 

[boblarson]

Check out my sample here which uses a listbox and you never have to type any name of any report at all. All you have to do is to name a report starting with rpt_ and it will then show up in the list.
http://downloads.btabdevelopment.com/Samples/listbox/SampleSelectReportFromForm.zip

 

[purchaandr]

Hey there Bob,

That was exactly what I was looking for. However, I don't quite understand how this query works? What is MsysObjects doing? Is that just looking at all the tables, forms, queries and reports being system objects and the ".Name" looking at what their names are?

SELECT MsysObjects.Name, Mid([Name],5) AS QueryName FROM MsysObjects WHERE (((Left([Name],4))="rpt_")) ORDER BY MsysObjects.Name;


Cheers,

Thanks again!

 

[boblarson]

MsysObjects is the system table which keeps track of the objects in the database. The query just pulls out the names of objects with the name that starts with rpt_ and it returns both the full name (for opening the report) and the part without the rpt_ so that it is more user friendly for viewing in the listbox.

 

[HiTechCoach]

I prefer to use a table to store the reports.

See the attached example:

 

[boblarson]

I prefer to use a table to store the reports.

See the attached example:

I used to as well, but I got tired of having to add the information to a table. So, I just started naming my reports with rpt_ if I wanted it to show up in the list and if I want it to be not in the list I name it without the rpt_ or just rptReportName. Simplifies things as far I was concerned. But yes, you can use a table if you want to do that and there's nothing wrong with that.

 

[thatlem]

Here's an easier way. In the design view of the form, add a button and then select to "preview a report" Add button name, etc. Then when you click on the button, it will launch a print preview, where you can page through the report, zoom, etc. Then just print from the print icon. If you select quick print, you will get everything, but if you select Print - you will be able to select only which pages you want to print - helpfull for a big report or pages separated out by departments, etc.

 

[boblarson]

Here's an easier way. In the design view of the form, add a button and then select to "preview a report" Add button name, etc. Then when you click on the button, it will launch a print preview, where you can page through the report, zoom, etc. Then just print from the print icon. If you select quick print, you will get everything, but if you select Print - you will be able to select only which pages you want to print - helpfull for a big report or pages separated out by departments, etc.

not easier if you have a lot of reports. Too much maintenance. The system I posted will let you add a report to the list simply by naming a report with a certain prefix. That is actually MUCH easier and less work.

 

[HiTechCoach]

Here's an easier way. In the design view of the form, add a button and then select to "preview a report" Add button name, etc. Then when you click on the button, it will launch a print preview, where you can page through the report, zoom, etc. Then just print from the print icon. If you select quick print, you will get everything, but if you select Print - you will be able to select only which pages you want to print - helpfull for a big report or pages separated out by departments, etc.

thatlem,


I agree with Bob.

How will that be easier with 100's of reports? That would be a lot of command buttons.

I find that things that are "hard coded", like you are suggesting, make a database a lot harder to maintain/update. I find it better to make things data driven (from a table, property, etc) whenever possible. This can allow a databases to be maintained/updated, with very minimal code/design. Somethings even with no code/design changes.

 

[thatlem]

Ok Bob, I see your wisdom, especially with a lot of reports.

I duplicated your form and code and ran into a couple of issues. First, although I also have rpt_ at the front of all my reports, the rpt_ came over with the name of the report, and was not getting cut off as the code suggested. Also, how are you defining your print and print preview buttons. It appears that they are embedded, but you must be running some code to tell it to look at the selected report.

thanks

 

[HiTechCoach]

Check out my sample here which uses a listbox and you never have to type any name of any report at all. All you have to do is to name a report starting with rpt_ and it will then show up in the list.
http://downloads.btabdevelopment.com/Samples/listbox/SampleSelectReportFromForm.zip

Bob,

It is normally recommend and considered "Best Practice" to avoid the use of spaces in object names.

With your method, how do you avoid spaces in report names and still display a "user friendly" name?

 

[boblarson]

In 7 years of using this, I have always just used spaces in report names. I don't normally do that for most things, but I've not had any problems with that in that time period so if I use that technique (the list box with the query of the MsysObjects table) then I will just use spaces for the report names (i.e. rpt_My Report Here).

As you know Boyd, there are exceptions to every rule and as long as one is aware of what they are doing, it isn't always necessary to follow strict guidelines. I look at it pragmatically. Reports open fine with spaces (and actually use of Access with SharePoint really requires you to use spaces if you want any kind of user friendliness).

So, anyway that is my approach SOME of the time. There are a lot of times where there aren't going to be enough reports to worry about it. But, if I have hundreds of reports then I don't want to maintain a table and this allows me to do that.

 

[HiTechCoach]

In 7 years of using this, I have always just used spaces in report names. I don't normally do that for most things, but I've not had any problems with that in that time period so if I use that technique (the list box with the query of the MsysObjects table) then I will just use spaces for the report names (i.e. rpt_My Report Here).

As you know Boyd, there are exceptions to every rule and as long as one is aware of what they are doing, it isn't always necessary to follow strict guidelines. I look at it pragmatically. Reports open fine with spaces (and actually use of Access with SharePoint really requires you to use spaces if you want any kind of user friendliness).

So, anyway that is my approach SOME of the time. There are a lot of times where there aren't going to be enough reports to worry about it. But, if I have hundreds of reports then I don't want to maintain a table and this allows me to do that.

That is interesting about SharePoint.

I have used your method in the past for small databases with simple reports, but with a twist. I used the report's description property to hold a user friendly name (with spaces) that is display in the list box.

 

[GaryPanic]

coming in on the end of this -

i like both options ( and have borrowed/pinched both of them) the table method does seem easier in some ways - but I holding on to it - as my approach has been - the reports only appear if you are in the right area(accounts reports are only visible in accounts form etc

however i like and understand the merits of these reprots - it would probably -polish what i have been doing - rather than the gaffa tape solution i have been doing -

thanks to both of you - not sure which option i am going to use yet - but once i have made my mind up i would of forgotten from who i have pinched it from

regards

G

 

[HiTechCoach]

coming in on the end of this -

i like both options ( and have borrowed/pinched both of them) the table method does seem easier in some ways - but I holding on to it - as my approach has been - the reports only appear if you are in the right area(accounts reports are only visible in accounts form etc

however i like and understand the merits of these reprots - it would probably -polish what i have been doing - rather than the gaffa tape solution i have been doing -

thanks to both of you - not sure which option i am going to use yet - but once i have made my mind up i would of forgotten from who i have pinched it from

regards

G

One of the advantage to using a table to hold the list of report is that you can add a category field. Then you can limit the report list based on this value. This also is helpful when you have lots of reports when looking for a report.