I want to ask some question, which about that"
Create a Query which accept two parameters,Restaurant and Category, and display results showing Branch, Category, Description, Date,
Quantity, Price and Total Sales, where Total Sales is calculated as Quantity * Price.
How can I do that? Please help me,thanks
You might like to read: http://support.microsoft.com/kb/304352
A couple of things that are needed to fully answer your qestion:
Version of MS Access
Table structure
But with that said, the item you are looking for is accessible in the Query By Example (QBE) grid.
Unless you are doing somethign very tricky with the data types, then you can just type the name of your 'variable' in the Where section of the grid in the column of the field that you wish to be applying the criteria to:
[*parameter*]
When you run the query, this will cause a pop up window to display that you can put your parameter into and hey presto - all solved.
As mentioned above, you should also read the KB article referenced. You can also use standard form syntax to link the parameter to a form field.
*formname.fieldname*
Related
I realize that this question is quite basic. And I have found various answers on various other forums - all of which use SQL which for the purpose of this assignment (it is for school) I cannot use. I have to physically type the answer into the Field box.
The question reads as such: "Add a calculated field in the third column. Name the field ExtendedAmount. This field should multiply the quantity ordered (from the Order Details table) by the unit price for that item (from the Products table). This will calculate the total amount for each order. Format the calculated field as Currency and change the caption to Total Dollars. Change the Total row to Sum."
I have attached a screenshot of what I tried, in Design View, as well as the relationships of the tables required for the question and other parts of the query. When I click "Run" that is where I hit a snag - it provides and other box which says, "Enter Parameter Value" which as I understand it should be supplied by the Order Details Table.
Does anyone have any idea as to what I can do to fix this? Here is the expression I built as well --- ExtendedAmount: ([QuantityOrdered]*[UnitPrice])
Thanks,
Josh
The quantity field is called [Quantity], not [QuantityOrdered]. Adjust your expression accordingly.
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.
In the report I am building I have 2 data sets: one gives me, per user, per day, the total amount in that status; the other one gives me, per user, how many days in the date range the user actually showed up at work. Each of these data sets comes from its respective stored procedure. See screenshot.
The problem I have is that I need to report not the total time in status per user, but the average per day. So in the screenshot you can see that one user has 5 entries for 5 days worked and the other one has 3 entries for 4 days worked. simply because in one of those 4 days he didn't had that status at all.
I tried adding a calculated field to my "status" data set by using the lookup() function but it kept on giving me errors, which makes me think I don't quite know how to use it.
I also tried using group variables, and I was able to define it under group properties, but it never come up as an option to be used when writing an expression.
Any ideas using lookup(), variables or otherwise?
You're on the right track. Sounds like the Lookup function is exactly what you want.
Instead of trying to add the calculated field to the dataset, try putting it directly in the report item where you want this displayed.
Something along these lines should work:
=SUM(Fields!Available.Value)
/ Lookup(Fields!UserId.Value, Fields!UserId.Value, Fields!Days.Value , "NameOfDaysDataset")
If this isn't working, please post a few more details of your data sets, field names, and where you need this to appear.
In a report model I have some entities which have attributes which are integers (set to integer datatype) but should not be summed or aggregated in any way.
For examples ID's.
But when I create reports with the wizard, sometimes the report builder will try to sum the values even though it doesn't make sense to sum ID's.
For example let's say I have a list of cars sold in a month. In january I've sold 2 cars, one with the ID 101 and one with the ID 210. In report builder I will then - when using the wizard - get the number 311 for the summed values. I can remove it afterwards, but I would like this to not happen at all (since the end-users will be confused)
I need a way to say to the report model: This is an integer, but it is not really a number you should sum up
Well the wizard isn't perfect as you've found out. It does it's best in trying to figure out what to do. All that you can really do is remove =Sum(carID.value, "datasetname") when it automatically puts it there. Or if you don't need to sum anything at all delete the footer of the table. A workaround perhaps would be to do a Convert in your SQL to make your ID's a varchar.
If you drag an integer field onto the table it generates a sum by default. This is not always what you want - e.g. when the field is an Id or a status code that is the same for all rows shown.
Right-click the "<<Expr>>" and bring up the "Expression..." dialog. Replace "Sum" with "First" - e.g. =Sum(carID.value, "datasetname") becomes =First(carID.value, "datasetname") If the values are the same in all rows, then the first value will do. If not, there are also other functions like Last, Min, Max.
This is a bit of a kludge, but it works for me. I used my text editor to edit the RDL (XML) file and replace "Sum(" with "", then searched (carefully) for the ")" and replaced with "". I only replaced this inside of the ... Reopen in report builder without issues.
I have an rdlc report file, and I am trying to make a sum which can only include the last item in each group. I have a table kind of like this:
Place = ? (Group header 1)
User = ? (Group header 2)
Date =Last(Fields!Number.Value) (Group header 3)
Number =Fields!Number.Value (Detail row)
So, in other words, in User there, I want a sum of Date... if that made sense...
The Numberrows contain many numbers per Date. But Date shows only the last number for that day, because the rest doesn't count (but must be displayed) In User I want to sum up those last numbers for all the dates for that user. And same with Place (which would be the sum of every last number for every day for every user).
Could anyone help me with this? I tried the obvious (to me at least) =Sum(Last(Fields!Number.Value)), but (also tried to specify the group in those functions, but didn't make a difference because) I get an error when I try to compile which says:
The Value expression for the textbox 'numberTextbox' contains an aggregate function (or RunningValue or RowNumber functions) in the argument to another aggregate function (or RunningValue). Aggregate functions cannot be nested inside other aggregate functions.
Which I guess kind of makes sense... but how do I do this then?
Update: I have solved the issue by adding another column, and copying those last numbers into that column. This way I can display all the numbers, and do the summing on the column that only contains the ones that is going to be in the sum. I am still very curious to if anyone have a solution to my original problem though... so please post an answer if you do!
Not sure I understand exactly what you're trying to do. Maybe something like =Last(Fields!Number.Value,"Group 1") + Last(Fields!Number.Value,"Group 2") + Last(Fields!Number.Value,"Group 3"), instead using a sum function?
the easiest way to do this would be to modify your dataset to only include the records your are displaying in the date field, that way you could just use a simple sum() instead of trying to do something weird and screwy and might not work.
Modifying the data set may really be the simplest solution, but if you really wanted to do this without complicating the query you could try "custom aggregation".
The exact techniques for this depend on the version of SSRS, and my understanding is it didn't really work that well before SSRS 2008.
The idea is, you write some custom code to maintain an array containing the last value for each date. One function updates the "last value" for a date, and another sums the values in the array. Your header calls the latter function; you conspire to cause the former function to be called once for each detail row before the header is processed.
Here's a blog with a write-up that explains the technique in SSRS 2008.
It also gives some insight into how you can try to make this work in SRSS 2005, but again apparently that's not as reliable.