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.