Constituent Merge in v11

Hi All,

Sorry to dredge up an old thread, but we have noticed this happening a lot more since we upgraded to V11 (nearly a year ago now) as well and it's suddenly coming to a head.  For several months after the upgrade we fell way behind on merging but decided we'd just have to live with it for a while.  In late spring/early summer, our box office staff was able to get completely caught up with merging.  Unfortunately, they are now beginning to fall behind again now that our season is about to start and things are getting busier.  I think that this "Merge Aborted" problem is likely a significant contributor to their inability to get through all of the merges each week.  In July and August, nearly 40% of all scheduled merges failed because at least one of the accounts was altered after the date it was identified as a duplicate.  (By the way, I only very recently realized that it was based off of the date that the duplicates were identified.  The wording of "since this was drafted for merging" or "since this was scheduled for merging", to me, makes it sound like it's based on the date the merge is actually scheduled by the user.)  It makes sense that so many would have been altered because part of our merge procedure has always involved some amount of account cleanup.  That is, we standardize address formats, correct misspellings, etc. on the account that we plan to keep.  In addition, it's our policy to always keep the oldest account when merging (due to internal preferences to not change patrons' account numbers), so that often means updating the primary contact info on the kept account so that the more recent info from the account to be deleted doesn't get merged in as inactive/non-primary.

There definitely seems to be some difference between V10 and V11 regarding this error, but I can't figure out what it would be.  The V10 AP_MERGE_CUSTOMER used the same criteria for producing this error (T_CUSTOMER.last_activity_date > T_POTENTIAL_DUPS.create_dt) as the V11 AP_MERGE_CUSTOMER.  I'm wondering whether T_CUSTOMER.last_activity_dt is being updated more frequently in V11 for some reason, as I believe Mo was implying above.  It is updated by TP_CUST_ACTIVITY_UPD, which I assume is called by the application when certain things happen.  Is there a chance that it's being called now every time you save anything in the customer record?  Could someone from TN speak to this?

I like your suggestion, Chris, about commenting out that code in AP_MERGE_CUSTOMER, but I'm not sure how our DBA (or TN for that matter) would feel about that since it's not a local procedure.  (She's on vacation this week or I'd ask her!)  As a long-term solution, I think it would be nice if there were a T_DEFAULTS setting for that with a clause built into AP_MERGE_CUSTOMER that would skip that portion of the error checking if it was turned off.

As for now, I'm a little stumped.  Has anyone else found a creative way of getting past this issue?  Has anyone not experienced this issue at all?  And if not, do you have any insights into why you haven't?

Any advice would be appreciated!

Thanks,
Bryan Evans
Manager of Data Analysis
Cincinnati Symphony and Pops Orchestra 

Hi Bryan

I suspect that you could effectively bypass that check, without editing Tess code (which I would certainly try to avoid)  by running a script, immediately before the merge job each time, to reset the create_dt fields for your merge pairs.

Ie something like 

update [dbo].t_potential_dups pd

set pd.create_dt = getdate()

where pd.status in ('K', 'D')

/Ken

Hi Bryan

I suspect that you could effectively bypass that check, without editing Tess code (which I would certainly try to avoid)  by running a script, immediately before the merge job each time, to reset the create_dt fields for your merge pairs.

Ie something like 

update [dbo].t_potential_dups pd

set pd.create_dt = getdate()

where pd.status in ('K', 'D')

/Ken

Ken,

That is both brilliant and obvious!  (Why didn't I think of that?!)

You've made my day.

Thanks,
Bryan