I'm currently in the process of creating an extensive Access report (~50 calculated fields) for a client and while I've gotten 99% of the report down, I'm having trouble handling the Sum and Count logic on the report.
In a nutshell, the report is intended to list the attendees at an event, tally up the number of attendees at each track/course, and also list any outstanding dues which will be paid at the door. In addition, and this is where I'm having trouble, the report also shows the revenue from each track/course along with a breakdown of the revenue from commuters vs. people staying overnight.
At the moment, all of the formulas follow fairly similar structures so despite having 50 fields, 99% of those are simply adjusting the fields to fit the relevant variables.
For the report now with revenue, my issue is that although I have the fee data specified in the data tables, Microsoft Access keeps zeroing out the calculations rather than displaying the total on the fly.
Here's two of the formals I'm using:
=((Count([W1]))*[Fee Charged W1])
=Sum([Room & Meals])
Earlier today I think I pinpointed the problem to the fact that Microsoft Access is showing the report essentially per individual rather than displaying one report for the entire dataset. I've confirmed this because I manually checked the data and noticed some fields had null values which explained the null tallies.
My question now is whether there is a way to assign a default value for variables in reports so that the report cancels out any invalid data in the database table? I imagine using VBA would help, but I have little experience in that realm.
Thanks very much in advance for any assistance
Just found the solution which was right under my nose the entire time. I just had to configure the fields to use a Running Sum (also called a Cumulative Total).
The answer came right from a page in the Microsoft Office Website: http://office.microsoft.com/en-us/access-help/summing-in-reports-HA001122444.aspx
Related
I'm attempting to create a report in Access 2016 that resembles a bank deposit slip however I've been unable to find any way to display anything more than one record per report.
I have a query "Transactions" that sorts everything out and gives a datasheet with all the transactions to be used, the goal is to populate the report with up to around 12 different values from different transactions.
Is this even possible within access? My only thought thus far is to create a table with individual columns for each transaction, but that just seems messy.
Thanks for the help
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.
I am trying to add a few totals (sums and counts) using the wizard to an Access report. When I add them to the report and try to view the report, the report fails. Without the totals the report will display. The only thing I can figure that may be a factor is that the query being run to populate the report takes a bit to execute. The query runs a series of other queries which takes longer than normal to generate the report.
ETA: Thank you dmoody007 for your help in rooting out the problem and confirming my suspicions.
The question is a little vague. Any of these can either display errors or cause the report to not run.
Use Control Name in detail section of report for totals field (example: Name is Overtime so total of overtime should appear like =Sum([OverTime]))
Be careful not to name your controls the same. Detail control can be named Overtime. Your total of overtime should NOT be named overtime as well. Name it like Tot_OverTime otherwise you could end up with a circular reference.
If counting a text field, know that null fields are an issue. Suggest counting identity seeds or fields you know always have a value.
Make sure each control in detail you plan to sum, is formatted for numbers. If you look at the control property, format should be a number and you can assign decimal places. If not, you need to check your query or source table to ensure field is properly assigned a format.
One good tip. Add one field to total at a time. A little tedious but ensures one works before adding the next. Always recommend this to newbies until they get real comfortable making reports. Easier to debug.
Good Luck.
I'm currently in the process of coding a summary report in Access XP for a client and while for the most part I've gotten 99% of the fields to match correctly with the original report (created in Corel Paradox 4.0), I'm having an issue with a sum field where despite using the same set of data, I'm getting invalid answers.
For example, in one table, the sum of the fee field comes to 9,050 in the Paradox report. In Access, the table containing the data also comes to that same amount. Despite this, when I enter the expression in my Summary report, Access will always display the total as 9,005.
I've been trying to use the NZ function to cancel any nulls, however that hasn't helped. Changing the number format to currency, general, and other formats also hasn't been helping.
Any assistance/insights are greatly appreciated.
EDIT: As requested below are some of the expressions from my Access report. Everything up till now has strictly been Access code, but as I have SQL experience, I am open to implementing that type of code if needed (it actually has been on my mind for a bit)
=nz(Sum([Fee]))
Calculates just the total fees
=nz(Sum([Room & Meals]))+(nz(Sum([Commutter & Meals])))+(nz(Sum([Fee])))
This we use to calculate the grand total. It also comes out identical to the fee total for my dummy data since the first two fields don't have any totals added to them.
Not sure this will help, but you need to break this down to trouble-shoot.
Capture the detail data from this report and compare to the Corel Paradox data. Don't just test the totals. Maybe you can put them in Excel.
Break out the three fields individually and sum those: Sum([Room & Meals, Sum([Commutter & Meals, Sum([Fee]). Don't format. Manually add them together to test.
Are these integers or is there some rounding going on?
Are the text boxes on the report large enough to display the entire number?
1 may show you're comparing apples to oranges.
I'm tasked with reporting on survey data using Reporting Services 2008.
My challenge is this:
a survey has any number of questions
a question is one of three types (a numerical eval, a yes/no question, or a free text)
To handle this, I decided to use subreports on my main report, e.g. I defined one report for each of the three question types, and now when I'm reporting on a survey, I basically dynamically create a RDL for the survey report, using the three question types as subreports.
That actually works quite nicely so far - but I'm facing one major problem: how do I get the data into the subreports?
The approach I see right now is to have each (sub)report per question type define its own data set, based on a shared data source, to extract the values from the database. I'm pretty sure this would work - but I am not very keen on having potentially 5, 10, 20 subreports going off to the database to get their data independently.
What I was hoping for was being able to go fetch the data once for the whole survey, on the "main" report, and then just feed the appropriate subset of data into each subreport, as its being rendered - but I can't seem to find any way to do this....
Am I missing something totally obvious? I haven't had much exposure to Reporting Services, and my last project with it was four years ago (with Reporting Services 2000) - so there's a good chance I am just blind for the obvious solution :-) Please let me know!
Thanks for any hints, pointers to good articles or blogs on Reporting Services, and any help at all!
Marc
The usual way is to pass parameters (like date range) from main report to subreports and then subreports take care of everything else. To improve performance, see if you can render subreports from cache or snapshot. The cache stores report with combination of parameters passed, so after first "database hit" some or most subreports may actually be returned from the cache.
I struggled with the same issue. But there is a way you can achieve reasonable performance using "cached shared dataset". Basically subreports will use larger dataset including all rows for all subreports. By using "dataset filter" each subreport can filter out rows properly.
This is only available for 2008 version however.
If the parameters are the final data you require, then just use them and create a dummy dataset in the subreport - you could just have 'SELECT 1 AS DUMMY' as the sql (this is assuming that the subreports have distinct layouts from one another)
Or perhaps you can rethink the 'master' dataset with a function or table function?
It would still tax the sql server, but at least it would be doing it in one hit and the drain on the RS box would be less.