I'm experimenting with Reports in MS-Access 2003 and I have to ask what value is there, if any, to adding interactive controls to a Report? This includes Command Buttons, Checkboxes, etc that are made inactive once the Report is viewed in its proper Print Layout.
I'm opposed in general to the use of user interface controls on reports, but it actually is an advantage that you can save a form as a report. That's one reason you could end up with interactive controls on a report.
Arguably, one can also justify combo boxes and option groups, the first because it saves a join in the report's recordsource (which might cause complications or performance issues), and the second because it provides not just an indication of the stored value, but also what it means and what the other options are.
Check boxes I see no issue with at all. They are a good way of indicating Boolean values.
Command buttons I can't justify, but are likely supported simply for the compatibility issue that allows you to save a form as a report.
Related
I am looking for some advice on strategically embedding reports in forms to allow for optimal end-user usage.
In particular, i would like to know if it is possible to have a report embedded into a form but so that the header of the report changes as you scroll down to show the title of the current type of record you are looking at.. As an example, i have a report with about 1000 lines of information relating to 5 category types.. I made a report so that the category type is Always in the header of the report. Is it possible when viewing this report embedded into a form to have this functionality??
Thank you,
A
A quick Google search indicates that Microsoft does have an ActiveX control available which does allow you to embed reports inside forms. It's called the Microsoft ActiveX Snapshot Viewer. Most of the search results indicate that there are vulnerabilities with it, which is often the case with old ActiveX controls.
Even if you do utilize it (which I do not recommend), you're going to run into a problem where you won't know what category the user is viewing, since I'm not aware that Access gives you any way to get that information.
I suggest you use forms instead. Reports are for printing, and in my opinion, for nothing more than that. A preview should allow the user to see very quickly what it will look like, and then print it.
It isn't that hard to build forms that allow users to search/filter. I find that when I build proper searching/filtering forms, my users don't need reports unless they really do need to print something. Forms can be built as read only so they can't change data.
Be aware that even with forms, I don't think it's possible to know what the user is viewing. If they click into a record you would be able to use the OnCurrent event to know what record they are viewing and could likely derive the category from that, but that requires them clicking around in forms. A much more standard way of doing this would be to give them a dropdown which would allow them to select a category and apply a filter to the form (or a subform) to view only that category.
What is the difference between bound and unbound controls in MS Access?
How do they differ? And when on an MS Access Form in design view, how can we tell if a form is bound or not?
Bound elements are linked directly back to the relevant tables, and when you amend any data within form's, your changes are immediately written to the tables. This can often lead to people questioning why "when I close a form does it save the changes?" Well that's bound behaviour for you, and to prevent any updates you must use procedures such as BeforeUpdate to cancel if necessary. Bound controls are easy to identify as they will contain the field names from the table in design view.
Unbound forms are quite the opposite, they are not tied directly to database fields and involve more coding work in order to initially populate them in normal view. However these will not automatically make changes to your tables without a custom procedure you have written e.g. a Save button. This allows a little more control, but also involves more work and good understanding of VBA coding. Unbound controls are also easy to identify as they will contain the word unbound in design view.
Note: There is much more can be said but this is a basic outline.
A bound control is one that is bound to a field in a table or to a function. An unbound control has no Control Source property, similarly, a bound form has no Record Source. You can check the property sheet.
I would like to create an Access report in which the record source is created via ADO code and then set as the record source for the report when the report is run. The problem I am running into is how to add fields to the report since the recordset is bound to the report at run-time and not design time. Is there way I can manually add the field and make sure the field name matches what will be provided in the recordset field collection? Thank you.
The standard solution to this problem is to add all your fields in design view, up to the max available, and hide all of them, and show only the ones you need. Michael Kaplan explained that when he designed the Access Replication Conflict Resolver, this is the approach he used, precisely because adding controls at runtime quickly uses the lifetime limit on the number of controls on a form (700+, but I can't recall the exact number).
It's also just a bad idea, as #Jeff O says, to do design changes at runtime. For one, it means you can never distribute an MDE.
Several ways to do it, but all of them have their issues. create-dynamic report using vba
Other questions have found the folley in working in design mode programatically.
I have an old Access database that is being upgraded to work with Access 2007. The client is complaining that it is slow now. I am looking for ways to optimize it.
There is one subform that is in a particular tab on the form. I have been wondering -- does the subform still update/query even when it is not visible?
If this is configurable --- how?
All controls refresh/update whether visible or not.
It's generally considered good practice to not load recordsets until they are needed. If you have many subforms in a tab control, you can use the tab control's OnChange event to load/unload your subforms, or, alternatively, to set the recordsources.
However, with only a couple of subforms, this is not likely to be a big help. But with a half dozen or so, it's a different issue.
You can remove the recordsource from the subform and add it back when the form is made visible, or simply remove the whole subform and add that back.
Is there a way to change SQL Reporting "chart type" and "sub type" at runtime?
I'm working with a .rdlc report and can't seem to figure out the way to change this at runtime. I don't have the "Expression" ability in either of these fields.
Looks like it may not be possible until 2008: Microsoft Link
Your .rdlc file is where everything is defined about your report, including report type. So in cases where I want to change something about the report, I just modify the rdlc file using my favorite xml editing method (XmlDocument, XPath, etc.). You would just modify your RDLC file on the fly to change the report type, then display, or save, whatever.
I did this to allow users to set their own report colors, for example, since those are defined in the rdlc as well.
I am trying to do this exact same thing. I have a set of measures that are shown and then a chart underneath that will show only one measure at a time, depending on user input (which of the measures they wish to see in chart form). However, certain measures are better as columns instead of lines, so I'd like to change the chart type at render-time.
My initial idea is to overlap two charts and set their visibility opposite of each other and according to the user dropdown input. Seems like there could be an easier way (if that idea would even work in the first place?)
Thanks.
I'm using 2008 and it is not solved there as far as I can see. There are so many options for chart type and then even more on subtype, I wouldn't want to have to render them all and then show or hide the right one.
I'm wondering if there is a way to parse the XML of the .rdlc and feed it back to the report viewer without having every user getting there own new modified version of the actual .rdlc file.
On a side note, MS just released a new charting package (from the acquisition of Dundas). Maybe I'll dump the report idea and go with the mschart server control.
One possible solution could be to generate both the charts you wanted and then hide one of them based on your requirement.
Think multiple Values and Visibility. If all other variables are constant (i.e., category, series, etc), simply add a Value for each of the desired chart type, and use a parameter to control value visibility. Elegant and simple.