I have a small little Access program that sums hours of employees, with queries for Daily, Weekly, Monthly, and from the start of the year, all accessed from an easy to read form.
I have been asked to make an option group to filter employees by fulltime, seasonal, or both. But an issue I have is that I can only access the PAYRULENAME from the table which begins 'FT' for Fulltime such as FTADBRK1 but Seasonal can be a whole mishmash of possibilities, just not beginning with "FT". Still, I did not think this to be an issue.
Since I already have the original queries done, I thought I could simply add an additional column and constraint for each query instead of making additional queries. So I tried some various methods. Such as:
Switch([Forms]![MyForm]![EmpType].Value="FT",Left([PAYRULENAME],2)="FT",[Forms]![MyForm]![EmpType].Value="S",Left([PAYRULENAME],2)<>"FT"[Forms]![MyForm]![EmpType].Value="All",[PAYRULENAME])
Where EmpType is a textbox that programmatically gives a value for the option group instead of 1,2, or 3. This works and I don't think this is where the issue is.
But using the above switch function gives a -1 for Fulltime or a 0 for Seasonal (S) and doesn't filter the query. (The last option is fine - but it would be nice to give an FT or S in a column instead of the entire PAYRULENAME).
I have also tried nested iif statements to no avail. Here is one: IIF([Forms]![MyForm]![EmpType].Value="All",[PAYRULENAME],IIF([Forms]![MyForm]![EmpType].Value="FT",Left([PAYRULENAME],2)="FT",Left([PAYRULENAME],2)<>"FT"))
Any suggestions would be appreciated!
Related
Can i use another column in InList clause?
Example,
i have created a variable and below is the formula.
IF [query1.column1] inList ([query2.column2]) then SUM([query1.amountColumn])
Else 0
OR is it possible to put variable after inList in formula?
If not possible -- is there any other alternative to this?
I see two possible approaches. I will to use the eFashion universe for both solutions.
Solution #1
Here are my 2 queries to begin...
Run your queries. Click on the columns you want to compare, [query1].[column1] and [query2].[column2] in your case; [Query 1].[Month] and [Query 2].[Month] for me. Right-click and merge them. They must be dimensions and of the same data type.
Now create a variable based on [Query 2].[Month Name] which you can filter on to eliminate the results from Query 1 that do not match up to anything in Query 2.
[UV Month Name]=[Query 2].[Month Name]
The key here is you need to change the Qualification to "Detail" and set the Associated Dimension to what we just merged by clicking three dots to the right. Choose [Month Name] not from either query, but the merged dimension.
Now build out your table with whatever object you want from Query 1 and add in the variable we just created.
Now add a filter on that variable to only show row where it is not null.
And you are done.
Pros
Works when limiting query (query2) has a relatively large number of values (compare to Cons for Solution #2).
Cons
More complicated to set up
May run into universe or performance issues related to query being filtered (query1).
Solution #2
Building upon Solution #1, I duplicated Query 1 and renamed it Query 3. Now you can choose "Results from another query" to get the [query1].[column1] InList ([query2].[column2]) logic you want.
If you take this approach then you don't need to do the merge, variable, and filter. The results of the query are filter before being returned by the report.
Pros
Simple
Cons
The number of values coming from your second query must be relatively small. It varies by database or maybe even your universe. I have found if it is over 1,000 values I get an error when I run the query that it is "too complex".
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 am a little new to building this but have come a long way.
I have built a db using Access 2007. I have a table that shows the employees info:
Lname
Fname
Status
HireDate
TermDate
(Status: they are either inactive (potential Hires), Active or Terminated)
I can run a query that will show me all the employees by hire date or run one to show term dates.
We would like to have a query that will give us a count of how many drivers are still there within a given month.
Say Joe Smith was hired on 01/01/2008 and was terminated on 05/15/2011. If I ran a report in 2011 on May 31st how would I need to build the query to show this employee as being there in the month of May?
I have used >=Date() and others. I could use between #05/01/2011# and #06/01/2011# in the criteria under TermDate but if there is not a date there, nothing shows up. I have even dropped down a line and added "Null" and still nothing or I get all the employees that are still there and the ones that was terminated before the dates. I'm not sure what I am doing wrong.
I'm unsure about the logic for the filter criteria on this one. I think your goal is to identify all drivers who were on staff during any part of May 2011. My best guess is you need at least 2 conditions to identify them.
HireDate prior to June 1, 2011
TermDate either Null or >= May 1, 2011
If those conditions are sufficient, the SQL could be fairly easy.
SELECT e.Lname, e.Fname
FROM employees_info AS e
WHERE
e.HireDate < #2011-6-1#
AND
(
e.TermDate Is Null
OR
e.TermDate >= #2011-5-1#
);
It sounds like you're building the query in Design View ... which is a good and helpful feature. However, it's difficult to describe how to build that query in Design View. So I suggest you create a new query, switch to SQL View and paste in that SQL text. Replace employees_info with your actual table name, and fix any field names I misspelled.
If that query runs without error, you can flip back and forth between Design and SQL view, make a change in one, and examine how it is represented in the other view.
The SQL doesn't have to be formatted the way I wrote it. I chose that way in hopes it would make the WHERE logic clear. And if you make changes to the query from Design View, Access will reformat the SQL as it sees fit. However, the formatting change should not break the query.
I used yyyy-m-d format for the literal date values. That format avoids any possible confusion over which parts represent day and month, such as whether #05-01-2011# is intended to represent May 1st or Jan 5th. However, when you alter the query, Access may change them to mm-dd-yyyy format. (Sometimes its "helpful" impulses are annoying.)
I'm puzzled about one point. It seems you have one record per employee. If that is so, and an employee can leave for any reason and be re-hired later, it would be difficult to capture the different employment terms in a single record. If you're facing that situation, you may need to revise table designs.
If I misinterpreted your data, please show us a brief data sample, and the output you want from the query based on that sample. Good luck with this.
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.
I am creating a line chart from an Analysis Services cube, with a date category, a count data field, and a status series. Here's a screenshot to explain:
picasaweb.google.com/lh/photo/fP16V4sB18O1xSTrdDV-_A?authkey=Gv1sRgCLHRmcjwtI2mzAE
I want to add the blue total line, which sums all the statuses together.
I don't want to add a "Total" member to the Status dimension, because that wouldn't make sense. I've tried adding another data field and scoping it to sum everything, but I can't figure out how to make the series field only apply to a single data field—so this ends up duplicating all the statuses and getting 8 lines instead of 5.
This should be possible... I don't want to resort to writing SQL against the underlying database.
Alright so I figured out a reasonable solution in MDX. I think it would be better solved in SSRS, but I haven't figured that out yet.
The trick is to add the [Total] member to the result set, instead of adding it to the actual Dimension. Simplified MDX is here:
WITH
MEMBER [Execution Status].[Execution Status].[Total] AS
AGGREGATE([Execution Status].[Execution Status].[Pass].Siblings)
SELECT
{[Measures].[Count]} ON COLUMNS,
{[Execution Status].[Execution Status].Children,
[Execution Status].[Execution Status].[Total] } ON ROWS
FROM [CUBE]
This defines an additional member for Total which aggregates all the Statuses. Then all the Status members as well as the Total are returned. SSRS doesn't care--it still groups by the new set.
I did have some issues with getting the Aggregation to work, which is why I'm using [Pass].Siblings. [Execution Status].Children always returned (null), and [Execution Status].[All] returned 2x the correct answer, presumably because of the [All] member. I could manually enumerate all the statuses as well. Still not sure what the issue there is...