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.
Related
I have a subreport I am trying to link into my main report. The main report pulls back information from one database and the subreport pulls from another. I could use lookup, but I lose the ability to format so I was hoping to achieve this with a subreport.
I enter a date range via my parameters, and let's say I get 30 client/matter codes back. It page breaks at the end of each row, so the data for each client/matter ends up on its own report. The goal is for me to output a large number of reports based on date ranges. The subreport pulls in folder names, and just like the other information, the folders for only that client/matter should be on that report.
What's currently happening is on each report, it just lists ALL of the folders for ALL of the client matters on each and every report.
I've tried making the subreport an adjacent group (which you can see in the screenshot) and grouping on Client code and then matter code. I've tried making the client code and matter codes internal parameters in both reports in the hope that it help filtered. I also tried just inserting the subreport into a cell inside the matter_code group but not as a group itself.
I apologize in advance if my explanation doesn't make sense. I'm having a hard time trying to put this into words.
From your explanation I would assume that you have a subreport in a group but you are not passing anything through to it. Have you tried passing through parameters to the subreport that uniquely define the customer and the customer folders?
I would like to create a report which I can use as a sub-report multiple times on the same parent report. However, each occurrence of the subreport should have different values.
For instance, there is a table called DailyReport.
Records in this table contain:
Date, member, team, description
The sub reports should be for each team within a certain date range. However, the date range per subreport/team will not be the same.
So, if the date range for all teams was consistent, then I could create a single subreport, and do some Ordering on the resulting records to separate things out into teams.
However, with inconsistent date ranges, I can't utilize a single query, so the most straight forward solution I see is to create separate subreports and queries for each range of each team.
The problem with this solution is that if I decide to change the format of the subreports I must do so in each specific subreport--a lot of duplicate work.
I would like to create a generic query and subreport. The query and sub report would call VB functions which would return the relevant value.
This means my parent report has the same generic report on it multiple times. As each subreport is rendered, I would like to increment a value behind the scenes so that the functions which the generic query and subreport call know to return a different value.
However, it seems that's not how things work in Access. The subreports on a report are not rendered linearly. A subreport is created, and then "stamped" onto a report where ever required. This means that all of my generic subreports have the same data.
How can I define a generic report and query? Then plug in different values into the report and query while the report is being reused multiple times on the same parent report.
You need to look into the LinkMasterFields and LinkChildFields property of reports. They are designed for exactly this purpose -- to filter a subreport based on current data in the main report, without needing any code or even queries.
You are correct that LMF/LCF do not work on date ranges, only values. So use LMF/LCF for the team filter.
For the date range filtering, you can use an unbound form that launches the report as two parameters defined in the base query. Create frmLaunch, and add two text boxes minDate and maxDate. Set their Format property to Short Date so Access with interpret them correctly and provide the date pickers. Now modify the base query, adding two Date/Time parameters [Forms]![frmLaunch]![minDate] and [Forms]![frmLaunch]![maxDate]. Now, find your date field and set its criterion to Between [Forms]![frmLaunch]![minDate] and [Forms]![frmLaunch]![maxDate]. Add a button to frmLaunch that runs the code DoCmd.OpenReport "YourReportName", acViewPreview.
So, the goal was to make it possible to re-use the same sub-report multiple times on the same parent report, with full flexibility on how the subreport retrieves data.
I placed multiple instances of the same subreport on a parent report. On the subreports Open event I placed a line like
Me.Report.RecordSource = "SELECT * FROM someTable WHERE " & getCriteria()
nextCriteria()
Maybe its possible to pass a value that identifies which instance of the subreport is opening to the getCriteria function. Probably like a getCriteria(Me.Report.Name). But in this case I kept track of how many subreports had been produced in vb.
Unfortunately, if your subreport has controls which have a data source which is a vb function, all reports will show the same value for that control. To get around this I added something like getSomeValue() & "As [Some Value]" into the SELECT of the SQL statement above. Don't forget to add single quotes or hashes around getSomeValue() if you are passing a String or date.
That's basically it, it's a pain. But I couldn't find a more elegant way to do it.
Edit:
One major caveat I experience with doing this, is that although the print preview works correctly, when actually printing or exporting to PDF, some subreports would not be included. Maybe there is something else causing this...
I have a report that contains several pages with graphs, tables and so on.
This report is used by different customers who always want small modifications to the report. At the moment if a customer wants a change on page 5 the whole report is recreated with the modifications, even though the only change is in the graph on page 5.
More so, some customers don't want to see page 3, others want a custom table at page 6.
My boss would like the report to be modular so he can simply switch parts on/off depending on what the customer wants. At the moment a change in a report means development followed by deployment.
My idea is to create a report with a number of subreports. Each graph/table would be a subreport so that if a change is needed we only need to change thàt specific subreport.
Ideally a dataset would be attached to the mainreport detailing which subreport to show: for customer X we would show SubreportX, Customer Y would see subreportY.
I know this can be done by adding all possible subreports to the mainreport and switching visibility per subreport but more elegant would be to dynamically decide which subreport to show. On drillthrough reports this is possible by using an expression to determine which report to open;
eg IIF(customer = X, "subreportX", "SubreportY")
but is this possible with subreports?
To be clear: I am looking for a way to decide dynamically at the moment of opening the report which subreports to show. Something like using an expression to get the name of the wanted subreport.
I have been searching for this (in VS2012 and through Google) but I cannot seem to find a definitive answer whether it is possible to decide at opening the report which subreports to show....
I found the following but again that seems merely to be using toggling visibility:
Dynamic subreport in SSRS 2008
I am very much hoping for suggestions, answers or even general directions. Thanks for thinking with me!
I would create a Dataset that returns the list of valid subreports for the selected Customer. I would add all the possible subreports to the master report. I would set the Visibility property of each sub-report using a Lookup expression, targeting that dataset.
I have a large project with a lot of reports, but the items in the reports are quite standard, reusable with parameters. So I've made subreports, that's OK. Now I assemble the reports by adding subreports to them by hand, plus setting the parameters, also by hand.
I think that this is not flexible enough, I'd like to have a table that defines the structure of the report: like one row per subreport, specifying the name and its parameter values. Then the report would be assembled together runtime in a list or something like that, by calling and inserting the subreport by name.
Is it possible somehow?
I can't think of a way to dynamically assemble a report like that without coding something that would generate the required RDL, upload it to the report server and then execute the report.
Another option might be to create one master report with all possible subreports in it. You could then use a table to control the visibility of each subreport, to simulate generating different reports. Obviously you don't want to execute long running queries for subreports that are hidden, so you would have to add a parameter to all your subreports so that if the subreport is hidden the dataset returns no data, e.g.
WHERE
(....) OR (#SubReportHidden = 'Hidden' AND 1=0)
I'm relatively new to SSRS 2005. I've built simple reports, and spreadsheets but I'm just beginning to delve into the world of fun that is SSRS/RDL. I'm trying to pass one (custom/non-query) parameter from one report (*.rdl) to another. While logically I would like to add a global variable, there doesn't seem to be any straightforward method/technique for doing what I want. It seems each page/report has its own parameters and reports aren't allowed to share each other's info.
I'm trying to simply hide objects/items based on an option that the user selects. Should a user select option A or B, I want to simply hide certain objects on multiple reports (within the same project) based on their selection. I simply check for the parameter value within an expression for the visibility property in any given object. Nothing complicated really. I've tested it out and on just one report by itself, it works. But try to get one report to read that value on another report, and there's no clear path in doing so.
Now as I've grown accustomed to SSRS, I believe there's the "normal" programmer's way and then there's the "SSRS" way. Both are mutually exclusive. So either I'm trying to do something that will never be allowed, it's a "built-by-design" feature and/or I'm going about it the wrong way.
Ideas? Suggestions? Maybe I'm going about this the wrong way.
Ok, so there's a only a few ways to pass parameters from one page to the next. I (eventually) discovered that I was simply trying to pass a boolean from one to the next. The data was not from the database, it was something manual ('true/false'). At first I thought I needed something akin to a global variable which there are a few built-in globals in SSRS. But as I found out, you can't add anything to that collection.
So on this one report I have an image pointing to the 'Next' page of the report. Within that object/image, you can set navigation parameters on that object/image. Makes sense so far.
On the following page, your report parameters must match the position in which the variable was listed from the following page. I guess SSRS passes a non-key based arrays from one report to the next so index/position is vital for getting the parameters right. Hence the arrows allowing you to adjust the parameter order. That was what tipped me off, but I thought it was SSRS was more adept then that in the sense that parameters being passed had to just match in name, not position.
(IMHO) as I see things, SSRS has/tries/must remain fairly static. There's no real sense of events, OO, etc. and yet SSRS seems to stitch elements from VB, VBA (expressions), SQL/T-SQL altogether and spew forth a usable product. I guess that's my newb perspective. I'm sure it will change with time.
Using subreports might allow you the functionality you need. Otherwise, the only other way I know of to "pass" parameters from one report to the next is using the query string.