• Replies 13 replies
  • Subscribers 338 subscribers
  • Views 539 views
  • Users 0 members are here
Related

Couple of things about V14.1 I have discovered

Peter Smurlick (Past Member)
$organization

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

  • $organization

    I'm so grateful for this, Peter! Thank you! We're gearing up for an upgrade in the fall and I'm so nervous, remembering how horrible the v12 upgrade was, with all kinds of little hidden bugs and issues just like this. Nice to have a list of things to look out for!

  • $organization
    Don’t forget that if you currently have scheduled reports running in v12 that were scheduled by a user that is now inactive, they won’t work in v14 unless the user is reactivated or the reports are assigned to someone else via sql code.  That was my biggest ‘gotcha’ when upgrading to v14/14.1
     
    Cheers,
    Kathleen
     
  • Former Member
    Former Member $organization
    The biggest challenge I am having is output element and parameter migration.  I have gotten a couple of emails from Tessitura support didn’t make it any easier.  I spent hours on this problem.  Finally I sent the emails and the report off to my consultant and he scratched his head for a while.  He finally figured it out and will be documenting the corrections he had to make in TEST so it will be easier in LIVE.
     
    Jason Song
    Scottsdale Arts
    IT Manager
     
    T: 480-425-5340   C: 480-529-4653
     
  • $organization

    Hi everyone,


    The other issue I'm having in TEST is my custom reports will not run.  I've got a ticket in but so far no solution.  Since the SQL exists and I know the most highly used reports I'm not all that worried if I need to re-create them ...


    The fun of it ....


    Peter


    ps the bunny which makes an evening stop by my lawn for dinner is here.

  • $organization
    Peter Smurlick (Past Member) said:

    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:

    Great: we have about 40 that are just "keyword_no = XXX", with no other conditions to swap.  I assume "1 = 1 and " will do the trick?

  • $organization in reply to Gawain Lavers

    Gawain,

    Although I'm not exactly sure what keyword_no error that Peter is referring to, I believe that this may have been an issue with the original release of v14.1, but it was fixed in service pack 2.

  • $organization in reply to Chuck Reif

    Thanks Chuck.  We're not there yet, but thinking of upgrading sometime next month.

  • $organization in reply to Former Member

    It was a very difficult decision for us about how to migrate list elements and output set elements.  We knew that we needed to change a lot of the way we were storing data particularly for output set elements, due to the new functionality that we wanted to provide--namely the runtime output set filters.  We knew up front that we were not going to be able to successfully convert everyone's output set elements because of the wide open flexibility that they provided.  We debated whether to not migrate any of them at all, script an entire new set of standard output set elements, and then have everyone re-enter their own custom ones.  Ultimately we decided that we could programmatically convert a large percentage of all output set elements and leave the rest for people to fix or re-enter.  Somewhat understandably this has created some question about which could be easily migrated and which couldn't and why we changed the format at all.  In the end I think the new functionality is well worth the effort involved in upgrading, but I think it's important for members to know that we never take these decisions lightly.

  • $organization

    Hi Chuck,


    The help ticket for our TEST upgrade to 14.1 is  ISSUE=76955 PROJ=24: Upgrade to 14.1.2 in TEST .

    Part way down there is a note to me from Teresa under Additional Information about the keyword issue.


    All the best


    Peter

  • $organization

    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

  • $organization in reply to Jess Levy

    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

  • $organization in reply to Jess Levy

    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

  • $organization in reply to Todd Lantry (he/him)

    This was super helpful!! Thanks!