• Replies 8 replies
  • Subscribers 340 subscribers
  • Views 139 views
  • Users 0 members are here
Related

Identify Duplicates in Constituent Import

Frances O'Connell
$organization

Hi everybody,

I have been doing a lot of constituent imports lately and am having a lot of trouble with the Identify Duplicates part of the Utility.  In essence, it doesn’t seem to be catching all of our duplicates.  I checked the Duplicate Matching settings in our T_DEFAULTS table and they seem to be sufficient, but regardless, it is not identifying duplicates even when they match these parameters – when the import name and address information is really, exactly the same as what exist in the db.  For reference, our duplicate matching settings are as follows:

fname=1,lname=20,postal_code=3,street1=3

Has anyone seen this happen before?  To note, we are still on v.10. 

Thanks!

Frannie

Parents
  • $organization

    Hi Frannie,

    I'm working on using Constituent Import to load in some schools and found this thread while troubleshooting duplicate resolution. Essentially, it's not finding any duplicates.

    I audited the procedure and found at least two bugs in the FT_DUPLICATES_FOR_NEW_CONSTITUENT that is causing the problem. One relates to reading our duplicate check values from T_DEFAULTS and the other relates to it skipping rows, like organizations and households, that have a NULL fname. I'm opening a TASK ticket to get this resolved and in the meantime, implementing some corrections myself so we can get this working properly. 

    Are the records you are having trouble with organizations, individuals, or a combination of the two? 

    Thanks,
    David 

  • $organization in reply to David Frederick

    Hi David,

    Thanks for chiming in!  All of the records we're importing are individuals.

    For the most recent round, I adjusted the @changed_since_days parameter per Dale's suggestion and I *think* the procedure might have caught more duplicates (?).  It is still not identifying all - it sounds like maybe the first bug you mention, about the proc reading check values, could relate?

    At this point , I'm doing manual checks using homegrown SQL in conjunction with the built-in utility check for almost all imports, and sometimes, in the end, going person by person.  I tabled the issue for a few weeks, but am hoping there will be time in the summer to reach out to Tess Consulting to see if they can cook something more robust up for our org.  We do way too many imports to have it work halfway.

    Let me know if you come up with anything else, and good luck!

    Frannie

Reply
  • $organization in reply to David Frederick

    Hi David,

    Thanks for chiming in!  All of the records we're importing are individuals.

    For the most recent round, I adjusted the @changed_since_days parameter per Dale's suggestion and I *think* the procedure might have caught more duplicates (?).  It is still not identifying all - it sounds like maybe the first bug you mention, about the proc reading check values, could relate?

    At this point , I'm doing manual checks using homegrown SQL in conjunction with the built-in utility check for almost all imports, and sometimes, in the end, going person by person.  I tabled the issue for a few weeks, but am hoping there will be time in the summer to reach out to Tess Consulting to see if they can cook something more robust up for our org.  We do way too many imports to have it work halfway.

    Let me know if you come up with anything else, and good luck!

    Frannie

Children
No Data