Merge Procedure Advice?

Hi all,

We've always had a good number of failed merges each week due to the good ole "activity happened on the kept account" error. Sometimes I can see that something physically happened and so the error is legitimate (not that I always agree with it failing the merge because of that... but that's a different story). I also noticed a while ago that the LP_CUSTOMER_RANK was causing a lot of unwanted activity. Since we don't currently use ranking I disabled it which kind of helped.

But I find myself looking into this issue again as we've still been having a crazy number of merges failing each week and most of them are consistently the same people. This is what I've found and I'm looking for some advice on what other people have done.

The majority of the failures seem to be happening because of our nightly Manage Constituency updates. It's funny because most of these people have had the constituency for several months and the last_update_dt in TX_CONST_CUST is from several months ago. But their last_update_dt in T_CUSTOMER is for the exact time of the last constituency update run. How have other people gotten around this? Should I stop using the Manage Constituencies report and write up LPs to apply constituencies that don't modify the account unnecessarily?

This also leads me to wonder how I'll handle the ranking procedure and merges when we start using ranking in the future...

Thanks for any advice!

  • Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David

  • We had a lot of failures in the past for a very similar reason (that is nightly jobs stepping on the merge job).

  • Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

  • Hi Gawain,

    This sounds like it is no longer an issue... So I'm curious as to how you resolved it! Did you change how your nightly jobs work or was there some sort of customization to the merge procedure?

    Thanks! Beth

  • Unknown said:

    We've always had a good number of failed merges each week due to the good ole "activity happened on the kept account" error. Sometimes I can see that something physically happened and so the error is legitimate (not that I always agree with it failing the merge because of that... but that's a different story). [...]

    Thanks for any advice!

    If you're comfortable with modifying the SQL, it is possible to comment out the lines in AP_MERGE_CUSTOMER that perform this check. Yes, in general it's not a good idea to modify standard Tess sprocs, but several years ago this particular check had become annoying enough that we took the chance. Thousands of merges later, no regrets, just lots of time saved.

  • Thanks, Chris. I certainly have considered that very option... It's good to know that it worked well for you!

  • Two options that occur to me on this problem, Beth:

    • Increase the frequency of the merge process so it runs nightly, and schedule the constituency utility to run after the merge process.
    • Decrease the frequency of the constituency utility to weekly, and schedule it to run after the merge process.

    Some organization prefer a week's worth of time to work on merges, and slowing down the constituency process might not make sense for data accuracy, but just wanted to throw those out there.

    -Michael Wilcox, Tessitura Network

  • Hi Michael,

    Thanks for chiming in! Due to the nature of the constituencies we're maintaining nightly, the second option wouldn't work well for us. The first one wouldn't be ideal but it is something we can definitely take into consideration. Our merging staff do enjoy the luxury of having a week to schedule and check the merges but perhaps daily isn't unrealistic. I'll discuss it with them and see how they feel about it.

    Thanks!

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as it doesn't really make a lot of sense for last_activity_dt to be updated when there was no change (at least in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. You could probably filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

  • Sounds great! One last thing I'll throw out there for anyone else handling this problem (apologies if you already know this tip): If you have a duplicate constituent who you suspect will be affected by the last_activity_dt issue, typing the ID numbers directly into the Merge Constituents screen rather than using "Potential Duplicates" will override the restriction on last_activity_dt and allow the merge to proceed.

    -Michael

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as that date really shouldn’t be updated when no activity actually occurred (in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. I think you could filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Beth Hawryluk
    Sent: Thursday, October 23, 2014 11:57 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Merge Procedure Advice?

     

    Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

    From: David Frederick <bounce-davidfrederick9045@tessituranetwork.com>
    Sent: 10/23/2014 2:22:50 PM

    Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as that date really shouldn’t be updated when no activity actually occurred (in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. I think you could filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Beth Hawryluk
    Sent: Thursday, October 23, 2014 11:57 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Merge Procedure Advice?

     

    Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

    From: David Frederick <bounce-davidfrederick9045@tessituranetwork.com>
    Sent: 10/23/2014 2:22:50 PM

    Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as that date really shouldn’t be updated when no activity actually occurred (in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. I think you could filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Beth Hawryluk
    Sent: Thursday, October 23, 2014 11:57 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Merge Procedure Advice?

     

    Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

    From: David Frederick <bounce-davidfrederick9045@tessituranetwork.com>
    Sent: 10/23/2014 2:22:50 PM

    Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as that date really shouldn’t be updated when no activity actually occurred (in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. I think you could filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Beth Hawryluk
    Sent: Thursday, October 23, 2014 11:57 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Merge Procedure Advice?

     

    Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

    From: David Frederick <bounce-davidfrederick9045@tessituranetwork.com>
    Sent: 10/23/2014 2:22:50 PM

    Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Hi Beth,

     

    I looked at the code behind the Manage Constituency job, and you are correct – it is updating t_customer.last_activity_dt for all constituents in the specified list, even if it didn’t actually change anything. I would suggest opening a ticket with Tessitura on that, as that date really shouldn’t be updated when no activity actually occurred (in my opinion).

     

    You may also be able to refine your list criteria. I’m not sure what your Manage Constituency job(s) are doing, but I assume some are an action of Add to List. I think you could filter out constituents that already have the constituency you are trying to add, thus preventing the procedure from touching the last_activity_dt unnecessarily.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Beth Hawryluk
    Sent: Thursday, October 23, 2014 11:57 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Merge Procedure Advice?

     

    Hi David,

    Yes, the Manage Constituencies utility seems to be updating t_customer.last_activity_dt even if no changes were made to that particular account. I'm assuming simply because it needed to access the constituent record? I'm not really sure.

    Thanks! Beth

    From: David Frederick <bounce-davidfrederick9045@tessituranetwork.com>
    Sent: 10/23/2014 2:22:50 PM

    Hi Beth,

    The merge process looks at t_customer.last_activity_dt to determine if there has been activity since the last merge. It compares that against t_potential_dups.last_update_dt.

    Is there anything you are doing in your nightly jobs that is updating t_customer.last_activity_dt?

    Thanks,
    David




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!