Forum Discussion
Fixing Human Error on data entry - DAX use with Contains function without filter context
Hi,
I tried to fix some human error data from DAX, I need some help with how to resolve this row context and filter context.
This table shows our enrol application status history. In this particular case, the operator made a mistake. This student applied to the school in 2009 and attended the school for a few years and then left. Again, in 2020, they applied but the application was cancelled later. you can see the operator mistakenly marked the first application as cancelled as well which should not and the entry date made as new enrol date which should not.
What I want is for the second application to be marked as cancelled enrollment and the first application not cancelled
. I did the following DAX. I searched the enrol dates of Leaving Date < Enrol Date and Cancelled application. After that look at those enrolled dates in the Enroldate columns and mark them true or false. But, This doesn't work as planned, it looked like filter context work on the row level and it gives False for everything except cancelled status.
I need to mark all 2020 enrollment statuses as true on cancelenrol column. Then, I count real applications made enrollment.
** If I remove this condition FutureStudentStatusHistory[SynergyMeaning] = "cancelled", it worked fine but I want to know if the application is cancelled or not.
Table:
| EnrolDate | Campus | YearLevel | Status | ID | StatusChangedDate | StudentID | StudentLeavingDate | StudentEntryDate | StatusMeaning | CancelEnrol |
| 1-Jan-09 | NOR | 0 | CZ | 25648 | 28-Nov-19 | 25648 | 13/12/13 | 29/01/20 | CANCELLED | False |
| 1-Jan-09 | NOR | 0 | OFF | 25648 | 24-Jun-05 | 25648 | 13/12/13 | 29/01/20 | APPLICATION | False |
| 1-Jan-09 | NOR | 0 | CON | 25648 | 29-Aug-05 | 25648 | 13/12/13 | 29/01/20 | FINALISED | False |
| 1-Jan-09 | NOR | 0 | CON | 25648 | 14-Mar-19 | 25648 | 13/12/13 | 29/01/20 | FINALISED | False |
| 1-Jan-09 | NOR | 0 | CON | 25648 | 28-Nov-19 | 25648 | 13/12/13 | 29/01/20 | FINALISED | False |
| 1-Jan-09 | NOR | 0 | APP | 25648 | 20-Apr-04 | 25648 | 13/12/13 | 29/01/20 | APPLICATION | False |
| 1-Jan-20 | NOR | 8 | ENQ | 25648 | 14-Mar-19 | 25648 | 13/12/13 | 29/01/20 | ENQUIRY | False |
| 1-Jan-20 | SNR | 11 | CZ | 25648 | 28-Nov-19 | 25648 | 13/12/13 | 29/01/20 | CANCELLED | True |
| 1-Jan-20 | SNR | 11 | OFF | 25648 | 29-Apr-19 | 25648 | 13/12/13 | 29/01/20 | APPLICATION | False |
| 1-Jan-20 | SNR | 11 | CON | 25648 | 12-Jun-19 | 25648 | 13/12/13 | 29/01/20 | FINALISED | False |
| 1-Jan-20 | SNR | 11 | CON | 25648 | 28-Nov-19 | 25648 | 13/12/13 | 29/01/20 | FINALISED | False |
| 1-Jan-20 | SNR | 11 | APP | 25648 | 11-Apr-19 | 25648 | 13/12/13 | 29/01/20 | APPLICATION | False |
3 Replies
- lbendlinSuper User
How many of these human error data items do you have? Are you sure you need to automate this?
- AnonymousNot applicable
Hi lbendlin,
That's what I want to find, how many second applications. There are more than 50000 records. I want to know if this is negligible or not.
But my problem is when we do row level calculation how to avoid row filter? where should I use ALLEXCEPT or ALL functions? I add allexcept for IDs, and then it makes true for all records.- lbendlinSuper User
use REMOVEFILTERS - that is much more gentle.