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.
Oh no. This makes me very sad.
I'm afraid I view this as a retrograde step. Managing duplicate accounts is a bit enough task as it is without having to wait a day (and remember to do so) when trying to merge 3 accounts into one.
Another reason I'm happy to wait until moving from v15.0.5.
Hey Kevin,
Although I appreciate the amount of time that Support and Dev put into this, I have to wonder....was MAC at all involved in this decision? As you can see, this is affecting organizations negatively. It's unfortunate that this was rolled out and was not communicated before roll out. This is something that needs to be A1 priority for the next version. The merge process has always had it's issues. However...now Tessitura has made the process even more a bear for us, the clients. Since Tessitura does not provide any clean and effective way to manage duplicate account creation via web/mobile and now is requiring us to have to figure out new ways to manage merges that can include merging the same person over multiple days if they have many duplicate accounts (which happens ALL the time), I'd like to know what the Roadmap is for duplicate account creation management via web/mobile AND what Tessitura intends to do to fix this new issue that you've created.
- Chris
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
Because of the way we handle comp vouchers (creating an account for each pair, CSIing it, redeeming in that account and adding the constituent info) we can sometimes have hundreds of unused vouchers (constituent records with names like "A Christmas Carol Comps (2)" at the end of the season, and our business practice is to merge all of those unused accounts into a single account for the season so that we're not creating an additional burden on the system season over season - our database is large enough as it is - and so that we maintain a count of the unused vouchers (using the CSIs). This is a process we instituted nearly a decade ago, and which usually takes us maybe two days, and we haven't had a problem with that process yet; but this change is going to turn a two-day process into a never-ending process. These are accounts with no transactional data in them - it shouldn't require this much effort.
It sounds a lot like the time that S&D are spending troubleshooting merge errors is being passed onto the licensees who are already strapped for hours in the day - why not commit those efforts to more transparent resources for and education in merges so that errors can be avoided rather than putting the burden on the organizations that already have it well in-hand? There has to be a better solution, and I'd really like to hear one from the network that won't affect our existing business practices.