Hi all -
We just moved over into V15 - and we're working through some new features. We received this error for the first time "Constituents Can Only Be Scheduled Once for a Single Merge." We've never encountered this before in other versions. We've done our due diligence and read about merging in V15 - but can't figure out how to merge Account Numbers 2 and 3 into 1 during the same merge procedure. Any ideas where we are going wrong?
Also, is anyone using any jobs for merges overnight that they really like? We've been doing it manually for awhile now. I've worked for other organizations that had jobs that ran overnight that looked for potential duplicates, and I'm looking into possibilities of implementing this here.
Thank you!
Unknown said:We received this error for the first time "Constituents Can Only Be Scheduled Once for a Single Merge."
What version of Tessitura are you on? We are on 15.0.6 at the moment, and I can't find that text among impresario sprocs.
15.1.2
Unknown said:15.1.2
Cool. We'll be on that in Live soon enough. If I can track down where they're doing that check, I may comment it out.
Interesting, we am on 15.1.1, and I am definitely not experiencing that, so it must be a VERY recent change.
Here is the error message you get. I had scheduled 166265 in a merge and tried to schedule another account into that same account:
Chris,
Are you 15.1.2 as well, or on a previous version?
We are on V15.1.0
Well, that at least helps me to know that it just should be a client side irritant and our procedural stuff can continue unabated. Still irksome, though...
15.0.6 in Live, for now. Upgrading tomorrow AM, actually...
Upgraded to v15.1.2 this AM, and ran into this error already, Log Viewer reveals nothing, so I assume this error is compiled into the PB client(?). Are people really supposed to wait a day to merge >1 record? A terrible change to this process, a backward step. I'll work around via SQL, but shouldn't have to...
It really is not a great change. The rationale I was given was because of orphaned accounts and something related to analytics. What's even more annoying is that they fundamentally changed how merges work...but still didn't add the ability for us to mark possible dupes that are not dupes as such, so they don't continue populating in the potential dupes. IMHO - the who merge process needs an overhaul.
I'd highly recommend opening a support ticket though Chris and expressing your frustration and concern and ask this be moved to an enhancement request...or better yet...be reversed to the way it was pre-V15.1.
Christopher Cuhel said:something related to analytics.
You would think we'd want cleaner data expressly for Analytics. After all, what good is Analytics if you db is full of dupes? (I laugh when people ask about first time ticket buyers...)
Christopher Cuhel said:still didn't add the ability for us to mark possible dupes that are not dupes as such
There are still custom solutions, but, as you say, this should have been built-in years ago. Dupes are a problem every org in the network faces, and we're all kind of left to each re-invent the wheel.
Christopher Cuhel said:I'd highly recommend opening a support ticket though Chris and expressing your frustration and concern
Will do, at which time I'll also ask about the "this e-mail can't be deleted because it's associated with an order" error. How on earth is someone supposed to deal with that in the client?
I do think we hit duplicate management and data integrity pretty hard in that roadmap session, so hopefully some of that comes through. And the ability to mark potential dupes that are not dupes was definitely on that list.
But in any case, in agreement with all of this. Especially the e-mail/order issue.
Ah yes...that fun bit of problems. I ran into that a couple months ago as well and went "well, how am I supposed to deal with this issue then?" I have yet to figure out an easy way to fix that problem.
Hi all,
First, I want to apologize for missing noting this change in the v15.1 documentation. The merge topics have now been updated to note that a constituent can only be scheduled for one merge at a time, and the change has been noted in the What's New section as well.
I also want to share some background on the change provided by the Development team. There has been a significant amount of time spent by both Support and Development troubleshooting and fixing merge errors due to conflicts between accounts when a constituent was involved in multiple merges within a single merge process. Development determined that limiting a constituent to be involved in only one merge at a time was the best solution to prevent these errors based on the current structure and complexities of the merge procedures. As we continue to work on the Constituent UI overhaul and then move on to other areas of of Constituents, we will look at ways to improve the merge process. For the time being, though, this change is not going to be rolled back as that would reintroduce the merge errors members have been experiencing. Also note that the Network does not support manually inserting rows in T_POTENTIAL_DUPS or making alterations to the merge procedure as these practices could result in unintended/unexpected consequences.
Kevin Sheehan said:There has been a significant amount of time spent by both Support and Development troubleshooting and fixing merge errors due to conflicts between accounts when a constituent was involved in multiple merges within a single merge process.
Interesting. I've merged >1 "delete" record into a single "keep" record hundreds of times (at least) over the years, without a hiccup. I wonder what was different in the cases above.
Kevin Sheehan said:Also note that the Network does not support manually inserting rows in T_POTENTIAL_DUPS or making alterations to the merge procedure as these practices could result in unintended/unexpected consequences.
Naturally, no-one should alter or work around standard code unless they're prepared to un-merge or otherwise clean up after themselves, though it's sad we have to resort to such things when, I would argue, the software takes a backward step.
Just coming to this after the long weekend...
Additional question to this, I assume that you are saying this specifically in reference to the idea of getting around the client side prohibition of duplicate merges. However, that does take me back to the very initial comment of mine.
Our organization, like I am sure countless of other organizations, has a procedure in place to merge TNEW Guest accounts. This process DOES involve the, well, true it is part of a procedure, but otherwise manual inserting of rows into T_POTENTIAL_DUPS. Speaking for our organization only, there are no other custom updates to the merge process. But I think the Network can certainly understand how such a thing might be necessary. And there is absolutely no long term solution here by scheduling one merge and then another after that merge has been run. That would either require someone to sit there scheduling a merge, running the procedure and then doing that on repeat for a significant period of time every day or else writing a looped script to first schedule a merge and then run the merge procedure every time, which can be done no problem but then revisits the idea of "manually inserting rows" which is the process this is meant to avoid.
Thanks for your time. I am just making sure I am understanding everything correctly.
John