Reporting on the number of PAH patrons

Hi David,

I wanted to add a caution to using the new delivery method criterion in criteria sets you build going forward.  Adding new criteria is allowed and encouraged, but it’s important that you understand how any new criteria you add will work with other, existing criteria, particularly when it comes to orders.

For two or more criteria to be join together to find a single entry in a table that meets all the criteria, such as a single order with a delivery method you want and an order date you want, all the criteria need to be looking at the same table. Most of the standard order related criteria look at the ticket history table, while the new delivery method criterion you just added looks at the order table. So if you created a criteria set using the standard order date criterion and your new delivery method criterion, a constituent who has one order with a qualifying delivery method but not a qualifying order date and a second order with a qualifying order date but not a qualifying delivery method would meet the criteria and be selected for the list. For further illustration of how this works, see the IN and HAS operator help topics.

The key point here is that combining criteria that seem like they would be looking in the same place but are actually looking at different tables can lead to undesired results.  You can always double-check on where a criterion is looking by right-clicking on the criterion in the list of criteria in the left pane to open its technical details. If the Ref_table value for two criteria matches, they are looking in the same place and will work together as you would tend to expect (assuming you’ve selected the correct operator). If the Ref_table values don’t match, then they looking in different places and won’t combine to find a single thing (order, contribution, etc.) that meets both the criteria. You may want to name your new delivery method criterion in a way that makes it clear it’s looking at order tables and not ticket history tables so it’s less likely someone will use them together by mistake.

If you are on v12, you can probably change the criteria setup that Tom shared so that it can be combined with ticket history table criterion using sub-entity criterion setup, which lets you take one step away from the primary reference table.

Kevin Sheehan

Senior Technical Writer & Consultant

Tessitura Network

+1 888 643 5778 x 329

ksheehan@tessituranetwork.com

Hi David,

I wanted to add a caution to using the new delivery method criterion in criteria sets you build going forward.  Adding new criteria is allowed and encouraged, but it’s important that you understand how any new criteria you add will work with other, existing criteria, particularly when it comes to orders.

For two or more criteria to be join together to find a single entry in a table that meets all the criteria, such as a single order with a delivery method you want and an order date you want, all the criteria need to be looking at the same table. Most of the standard order related criteria look at the ticket history table, while the new delivery method criterion you just added looks at the order table. So if you created a criteria set using the standard order date criterion and your new delivery method criterion, a constituent who has one order with a qualifying delivery method but not a qualifying order date and a second order with a qualifying order date but not a qualifying delivery method would meet the criteria and be selected for the list. For further illustration of how this works, see the IN and HAS operator help topics.

The key point here is that combining criteria that seem like they would be looking in the same place but are actually looking at different tables can lead to undesired results.  You can always double-check on where a criterion is looking by right-clicking on the criterion in the list of criteria in the left pane to open its technical details. If the Ref_table value for two criteria matches, they are looking in the same place and will work together as you would tend to expect (assuming you’ve selected the correct operator). If the Ref_table values don’t match, then they looking in different places and won’t combine to find a single thing (order, contribution, etc.) that meets both the criteria. You may want to name your new delivery method criterion in a way that makes it clear it’s looking at order tables and not ticket history tables so it’s less likely someone will use them together by mistake.

If you are on v12, you can probably change the criteria setup that Tom shared so that it can be combined with ticket history table criterion using sub-entity criterion setup, which lets you take one step away from the primary reference table.

Kevin Sheehan

Senior Technical Writer & Consultant

Tessitura Network

+1 888 643 5778 x 329

ksheehan@tessituranetwork.com