Folks,
I've been using Advanced Queries for several small custom reports lately, and they've been very useful. I was working on a report using the Student HESA Object, as it has some useful available fields. I was curious that there are many of the Attributes I can't set as Criteria for the overall Expression. I've attached an example - I was hoping to use DegreeTrack.Name as one of the criteria so I could filter out students on Degree Tracks I'm not interested in, but I can't seem to get it to recognise itself as C2!
Is there a reason for that? There may be a perfectly good one I'm just not aware of, but I wanted to know in case I was just missing something ...
Thanks!
Status:
Answered
Hello,
The .... Before a Attribute indicates that it is part of a sub entity. We use the analogy of a Parent to a child. So the above example the Parent (Student) needs to be Active. All active parents will be in the results. The parents might have children, and the filter of children says, only keep children results that have the name of Bob. That will kick out children that are not named Bob but it was not indicating that you wanted to kick out the Parents, who had no children named Bob. To do that you select the "Action" ANY, and then select the Scope of "Student" (In this case, see below for nuance). This will now tell the system that you want Active Parents, but only the ones who have any chidren named Bob. The system will Place a Condition, like C1,C2,C3. If there is no Condition number next to the Attribute then you can know that the results will not be whittled down by that condition.
Conditions are only on "root". Meaning all query objects have a "root" or following the above analogy first generation Parents. Most query objects will have the Student as the root, meaning the results are all based around students. In this case a "person" that does not have a student role/profile will never be able to be in the query as the query starts at its root on Student. If you wanted to do a query on all People in the system then you would need to start with a query object with "person" as the root or first generation parent. In the "person" query object the "student" record would be a child to the "person" record. So for a "person" query object the Conditions would be applied to the "person" and not the "student".
Without going into detail, it is possible to restrict multiple levels of Parents. For example in a query object with the Root being Person. You can restrict on multiple levels, something like this: Give me only Religion major students (child to Student), only Active Students(child to Person), give me only the People that are students (Person parent restriction). In this example we would still get the result of all students in the system. but it would only show the data for Active Students that are religion majors. To remove the other students the religion major and the active students would need to be also set to ANY Person so that they effected the selection of people in addition to what information is inlcuded.
*GNECsis Support Specialist*