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

  • Since Peter's reply seemed to go out via email but didn't post to the forum, I'm pasting it in here to make sure it's archived:

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

    Hi Jess,

    The thing is the friendly folks at RAMP gave me a script to run following their work on the upgrade of our TEST site so I did not really know what was done.  In looking at my TR_Query_Element data there is now a special group for each of the Attributes which can have multiple values i.e. Attribute Contract Restrictions the options No Mail, No Email, No TeleMktg etc.  Those Attributes with a single value are still part of a single group.

    Other things I have discovered:

    - the New Contribution Report is now in SSRS so I had to re-schedule it.

    - the job que in SQL was not fully rebuilt so I had to have the update Ticket and Subscription history processes added along with the nightly merge routine.

    Peter

Reply
  • Since Peter's reply seemed to go out via email but didn't post to the forum, I'm pasting it in here to make sure it's archived:

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

    Hi Jess,

    The thing is the friendly folks at RAMP gave me a script to run following their work on the upgrade of our TEST site so I did not really know what was done.  In looking at my TR_Query_Element data there is now a special group for each of the Attributes which can have multiple values i.e. Attribute Contract Restrictions the options No Mail, No Email, No TeleMktg etc.  Those Attributes with a single value are still part of a single group.

    Other things I have discovered:

    - the New Contribution Report is now in SSRS so I had to re-schedule it.

    - the job que in SQL was not fully rebuilt so I had to have the update Ticket and Subscription history processes added along with the nightly merge routine.

    Peter

Children
No Data