Potential duplicate records

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!

Parents
  • 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.

Reply
  • 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.

Children
No Data