Hi all,
I'm new to an organisation where it seems a lot of duplicate records were created during the V11 upgrade, mostly teachers affiliated to school records, i.e. EXACT matching records.
Strangely, they aren't being picked up as potential duplicates in the constituent merge utility. The values in Duplicate Matching in T_DEFAULTS are: fname=1,lname=20,postal_code=3,street1=10.
Creating an auto-merge script is definitely on the horizon but if anyone is privy to this issue, I'd love to hear from you, thanks!
Good day, Kevin
We, too, experience the same problem.
We finally flipped the Tessitura switch on, recently importing all constituent data from our legacy ticketing system.
I wrote many custom SQL queries to search for potential duplicates (and I always find many), but it is often a manual effort.
Our Duplicate Matching values are: fname=3, lname=3, postal_code=4, street1=3
However, I often find potential duplicates with the SQL code that are not picked up by the AP_IDENTIFY_DUPLICATES stored procedure.
I’ll try your Duplicate Matching values. If you find better values, please share.
And, if I can help, please contact me directly.
Regards
Wendell Baskin
Bass Hall – Fort Worth
wbaskin@basshall.com
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Kevin Madeira Sent: Thursday, July 25, 2013 20:36 To: Wendell Baskin Subject: [Tessitura Technical Forum] Potential duplicate records
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!
There is some art as well as science involved in finding dupes, due to the (sometimes wildly) inconsistent data in which dupes might be hiding. To me, your duplicate matching values look too strict. At the moment I use:
fname=2,lname=3,postal_code=4,street1=4
After some experimentation, I'm finding that this strikes a pretty good balance between including non-dupes and finding more actual dupes.
Like Wendell, I use other, non-standard sprocs to hunt for dupes as well, some of my own and some shared on TASK, at the conference, or here in the forums. A combination of different queries helps to find many more (but never all) of the dupes lurking out there.
Hi Kevin,
A teacher record and a school record would never be matched as a duplicate, nor could they be merged, because they are in different constituent categories. A school record is an organization record and a teacher record is an individual record. And even if right now the only data on the teacher record is the school’s address, the intention is that you have a separate record for the teacher and the school so they can be tracked separately. In v12, this will allow you to set the school as the owner of group orders, for example, and also record the teacher as the initiator so that the order shows on both records. Then if the teacher later leaves the school, you don’t lose the record of the groups she brought from that school. Also you can start to collect more personalized data about the teacher, and have multiple teachers linked to the same school.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Sorry I wasn't clear at first - there are duplicate *teacher* records affiliated to the same school so for example:
#123456 John Doe 1 Sydney Street SYDNEY 2000
#987654 John Doe 1 Sydney Street SYDNEY 2000
are both affiliated to the same school record.
They have exact matching addresses and are of same constituent type (individual).
Kevin,
You may want to check your parameters for the AP_IDENTIFY_DUPLICATES procedure as the parameters have changed from v10 to v11. In addition, you may want to look specifically at the changed_since_days parameter against the last_activity_dt or create_dt on the constituents you listed. If null, the procedure only looks at constituents changed since the last identify procedure has been run, or the last merge, and if specified only constituents that have changed in the time specified will be considered in the identification process.
Best,
Anna
Thanks, Anna, I've since discovered that the records' last_activity_dt have null values causing the issue.
Cheers,
Kevin