Couple of things about V14.1 I have discovered

1. Constituencies:

If you have constituencies which never expire then check the end date is either NULL or 01/01/2999.  There is a bug in V12 or maybe earlier when using constituencies as part of the criteria in List Manager and Extractions.  This has been fixed in V14.  We went from 14,000 accounts with a given constituency to 3,000 because of the end date being 01/01/1900.  Once the end date was re-set all was well.  The SQL for this is easy enough.

2. The Performance Base Price and Availability Report

This report has been changed from Infomaker to SSRS.  The result users will not initially see the report.  You need to head into security and provide access to the report.

3. TR_QUERY_ELEMENT

Basically the issue is that with v14, the data_where column can't have keyword_no = at the beginning of the statement.  Items in the where need to be swaped around.  This is a sample of what had to be done:

select * from tr_query_element
where data_where like '%keyword%'

update tr_query_element
set data_where = 'key_value = ''Do Not Trade'' and keyword_no = 408'
where id = 407

I'm sure more surprises await.

Peter

Parents
  • Hi Peter

    How did you end up solving your keyword_no in TR_QUERY_ELEMENT issue? We have a number of output set elements that used to be just based on keyword_no that I thought had migrated fine, but now I am running into weird issues every now and then with them. Sometimes they don't work in extractions and occasionally they pull in weird data. The only solution I have found so far is to create new rows in TR_QUERY_ELEMENT_GROUP so that each attribute has its own individual group. If you found a better way to deal with these elements, I would love to hear it. The idea of creating individual groups for each of our 40+ elements that used to be based on keyword_no is not really appealing....

    Thanks
    Jess Levy
    San Francisco Opera
    jlevy@sfopera.com

  • Sandra Ashby also replied to this as follows, which went out via email but unfortunately didn't post to the thread (we are investigating this):

    ****************************************

    Hi Jess

    All your attributes should be fine using the same Attributes Group that points to VXS_CUST_KEYWORD.

    What might be the issue is that in TR_QUERY_ELEMENT there is a new field called keyword_no … this is where you enter only the keyword_no for the Attribute you want the element to reference. What used to be keyword_no = 10, you would now just enter 10 into this field. And of course make sure all your Attribute Elements are connected to the Attribute Group.

    Usually, there wouldn’t be any element parameters/filters for Attributes. So just check that there are none.

    If you are still having issues I would suggest opening a Support Ticket if you haven’t already.

    Cheers

    Sandra

Reply
  • Sandra Ashby also replied to this as follows, which went out via email but unfortunately didn't post to the thread (we are investigating this):

    ****************************************

    Hi Jess

    All your attributes should be fine using the same Attributes Group that points to VXS_CUST_KEYWORD.

    What might be the issue is that in TR_QUERY_ELEMENT there is a new field called keyword_no … this is where you enter only the keyword_no for the Attribute you want the element to reference. What used to be keyword_no = 10, you would now just enter 10 into this field. And of course make sure all your Attribute Elements are connected to the Attribute Group.

    Usually, there wouldn’t be any element parameters/filters for Attributes. So just check that there are none.

    If you are still having issues I would suggest opening a Support Ticket if you haven’t already.

    Cheers

    Sandra

Children