I haven't worked in Access in quite some time. But, I have a report that has a main query, with grouping. The report is based on a database like this:
Each office has many divisions.
Each Division has many projects
So, I group by office. But, each division has a lot of other relationships I would like to include in the report. Like Staff members. Is there a way to create a secondary, and more, query and loop through that to add data to the report?
thanks
Yes you can do this with both forms and reports. You need the SubForm control. This allows you embed one form/report within another. You can also define which fields to join on. This allows the main/outer report to filter the sub/inner report.
The link above contains detailed instructions taken from the Office website.
Related
I have an Access database which I have restricted for end users as I do not want them interfering with tables, queries and the like.
Is it possible to develop a tool so that users can select the fields they want to include in a report and then produce said report themselves?
Effectively, I mostly want to replicate the Query Builder function in Access because users do not have access to this due to the (necessary) system restrictions that I have put in place.
Ideally, this is how it will work. End users will:
Open Report function and are presented with a list of tables
Choose required fields.
Add criteria.
Run report.
Can this be / has something like this been done? Does anyone have any examples of such a feature?
I have reports generated by queries. I have some people who are not Access savvy (at all). Can I create a report that when opened, asks a couple questions, then generates the report based on how the person answered? I have very very limited VBA skills (but willing to learn). If I can keep them from opening Queries, it may be easier for them to get the information correct.
For example. I have a report that provides all the open records for all our sales people. Rather than create 10 different reports (one for each sales person, and 1 that is shows everyone), can I have the report generated based on if the person who opens the reports wants to see all open records for all sales people or just those from one sales person? I have something similar for suppliers - which suppliers have open records (if I only want to a report for a specific supplier, versus all suppliers).
Thanks!
-Cheryl
Based on your comment about using parameters and personally running each needed report, a form is a much better option. Apart from allowing data validation, you can also use lookups to ensure the values being passed to the data source are legitimate.
Your form should have controls for each criteria field you plan to use to generate your report. To reference the form controls in your query, use this nomenclature:
[Forms]![NameOfYourForm]![NameOfYourControl]
Using the form reference will eliminate the need to build multiple iterations of the reports and queries. Keep in mind which criteria you may want to omit though, for example, a combobox of suppliers if NULL could return ALL suppliers, so your query would need to accommodate that.
The company I work for have an access database that is linked to a sql server table. The database is on a shared network location so it is used by lots of people in the company (with the annoying problem that only one person can use it at a time).
There are several forms that are used as a front end for the data and on one particular form there are combo boxes that are linked to other tables.
When a report is generated on the form the ID of the combobox is on the form (a GUID) and not the bound item of the combobox.
How can I get the bound items to appear on the form itself? The solution needs to be easy to do or something i can produce that can be regenerated as it's used by non technical people.
In order to make the database usable by many, simply give each user a copy of the front-end.
Forms should almost never be used for reports, the best thing to do is to build a query (the query design window will help) that references each of the relevant tables, for example, if the combobox contained a reference to person type and you might build a query like this for your report:
SELECT a.ID, a.SName, a.MainAddress, c.PersonType
FROM Addresses a
INNER JOIN PersonTypes c ''Or LEFT JOIN if data is missing
ON a.PersonTypeKey = c.PersonTypeKey
If this is not possible, perhaps you could explain in more detail exactly how the report is generated from the form.
I'm maintaining and occasionally modifying an Access 97 program that's still a crucial department tool for a very large US corporation.
A number of reports use a "totals" subreport that I cannot link using LinkChildFields \ LinkMasterFields. In each case, the main report can be filtered by numerous (or no) criteria via a "Reports Manager" form.
I've coped with this by using a generic function that opens any subreport in design view, and edits the .Filter property. Works 100% OK.
However, this prevents me from distributing the app as an .mde file, as Design view is unavailable in an mde.
I've tried every alternative I can think of:
setting the subform filter during Open event to that of the Parent (error)
using Docmd.ApplyFilter during Open event (does nothing at all in a subform)
Although this 'old' app suits the Department using it perfectly, their IT want to implement a 'big-picture solution', and I really don't want a competitor to have free access to a heck of a lot of complex business rules I've worked so hard on over the years.
Does anyone have any suggestions re the subform filtering, so I can use an mde?
MTIA
Why can't you link to the "totals" subreport using Link Child/Master? It should run off the same record source as the main report and aggregate over the records. In any case, if you can specify a filter criteria, you should be able to specify a domain aggregate criteria (dsum, dcount, dlookup etc) that returns the same values.
Dynamically editing the filter property in design view to make it work is a kludge. There is a reason that it difficult, not because the Access designers wanted to make it hard for you to embed subreports with dynamic criteria, but because it's a bad idea. Don't do it. There is something wrong with your report record source if you can't either join the subreport on record fields, or get rid of the subreport altogether and aggregate within the main report. You probably already know this, but you can aggregate (sum, count, etc) over the detail in a report in the report/page/group header/footer and give totals that way.
For example, if you were writing a report for a printable invoice, you could move everything above the line items into the report header, leave a line item as the report detail, and move everything below the line items into the report footer. Then you could do sum() over the detail fields to generate your subtotal then add tax, shipping etc. Another way to do this would be to use a subreport for the line items then try to calculate the totals externally, not as simple and way more fragile if the subreport changes.
Have you considered rewriting a query on which the subreport is based? The SQL string of a query is easy to change, and you will be able to make an mde using this method.
I have created a complex report in Microsoft Business Intelligence.
The report has its own (fairly complex) WHERE clause. Is it possible for the user to set the CreatedOn date as part of the criteria?
UPDATE
I was looking at this again. On a basic report (one table) if i import the report over one created with the report wizard, this give you the filter options and works.
On the more complex report that uses the union statement to pull data out of two tables the filter options are available however they have no effect, this is after removing the where clause.
END UPDATE
Thanks
Luke
I have been doing some research into this topic, and it appears that if you alias the fields and prefix them with CRMAF_ this allows you to add filtering. I'm going to look at this over the next few days and see how it works. However it has been noted that several people have been unable to get this to work correctly.
Please note you need to prefix both the table and fields.
You then can set the filter.