List criteria

Debbie,

Someone from Tessitura/RAMP can jump in and clarify if I am reading this wrongly, but I believe that this is controlled by the TR_QUERY_ELEMENT table.  In the Table Definition, the data_select column is VARCHAR(255), and thus, once you get to around 50 four digit numbers with commas (or fewer if you are up to five digit Production/Performance numbers), the Tessitura Client returns an error since it will not be able to put any more information in there.  At least, that fits with the experiences I have had.

By the way, I believe this holds true for ALL List Manager elements; it is just with those performance/production related ones that it ever seems to be an issue because most people are not selecting a list from people with any of 60 different prefix types.

You CAN use multiple instances of the same List Manager element even in the same list definition to get around this character limit.  You can also of course always go into manual edit and add a bunch more numbers if they are known, but it is not as user friendly that way.

John

Debbie,

Someone from Tessitura/RAMP can jump in and clarify if I am reading this wrongly, but I believe that this is controlled by the TR_QUERY_ELEMENT table.  In the Table Definition, the data_select column is VARCHAR(255), and thus, once you get to around 50 four digit numbers with commas (or fewer if you are up to five digit Production/Performance numbers), the Tessitura Client returns an error since it will not be able to put any more information in there.  At least, that fits with the experiences I have had.

By the way, I believe this holds true for ALL List Manager elements; it is just with those performance/production related ones that it ever seems to be an issue because most people are not selecting a list from people with any of 60 different prefix types.

You CAN use multiple instances of the same List Manager element even in the same list definition to get around this character limit.  You can also of course always go into manual edit and add a bunch more numbers if they are known, but it is not as user friendly that way.

John

Thanks John, that makes total sense. As TR_QUERY_ELEMENT is a standard table I can't make any change to it and it might have a knock on effect to something else even if I were able.

We will live with the limitation. It's not been an issue in the past. We just need to pull everyone sitting in specific seats for our Christmas Carol production because the sight line has changed and they need to be contacted. Hopefully it won't happen often.

Debbie

John A. Moskal II said:

You CAN use multiple instances of the same List Manager element even in the same list definition to get around this character limit.  You can also of course always go into manual edit and add a bunch more numbers if they are known, but it is not as user friendly that way.

Being wary that if you do so you might be setting up an AND constraint, i.e. customer has tickets to performances 1,2,3,4,5 AND customer has tickets to performances 6,7,8,9,10.  You can use the two panes to create an OR join, but you could only use one element in each.

More tedious, if you need more that two, would be to set up the query in an extraction, where each segment is effectively an OR for these purposes.

Thanks, Gawain!  Meant to add in something about the pitfalls of that method in my post but forgot.