Hi, I've created a STU constituency to add to accounts who have bought a student price type and had their ID checked when their tickets were scanned. I identified them via the Attendance by Performance report, saved to list and added using the Manage Constituency Utility. This was very quick & easy, but ideally I'd like to schedule the process going forward. However, I can't schedule saving a report to list and I can't find the right criteria to create a dynamic list - people who bought a student price type and were scanned in (during x period). Any ideas how I can automate this? Sadly I don't write SQL (yet).
I'm stream-of-conscious-ing this, so bear with me.The list criteria would be something like "Attended Date" = Yesterday, and "Ticket History Price Type" = X. The problem arises when the criteria combine- it's a bunch of overlaps, but it doesn't say "Show me everyone whose X Price Type was scanned as Attended Yesterday". Instead, it's something like "Show me everyone who attended yesterday, and who has bought Price Type X". They're similar, and they can yield the same result, but they're not the same thing! We've battled this before.
We looked for a list of members who've attended more than 5 unique performances in a given year, and ran into a similar problem- the logic of lists doesn't lend itself to this level of granularity. Our database admin was able to build a custom list criteria to give us the answers we needed, but I don't know how to speak that language fluently. I'll see if I can dig that custom criteria up for you
Adding to what Nathanael's idea.
What if you create two dynamic lists:
List A, with criteria of Attendance Date >= RunDate -1
List B, with any performance criteria with student price type that HAS List A. ( you could also add criteria for those who Do Not Have the constituency already)
You could then use List B in the manage constituency report.
I think that would get you the students you are looking for.
Hope that helps.
T.C.
Yes, I'm going to +1 this! I do it with attributes and it works great!
I always go with a manually entered query in this case. It's often easy to start with the two disjoint queries and then use that as a template to construct the one where the two clauses are referencing the same table at the same time.