function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
JetlagJetlag 

Huge number of duplicates

Hi,

I've been dealing with support who have been very helpful but am in a bit of a jam - heres the situation:

I received duplicate records while doing an upsert. I now have 4000+ duplicates. More than I can manually merge by hand.

Heres how it happened. I wanted to use the nice new upsert feature to eliminate the possibility of duplicates in the future - something that has long plagued us. I found that I had to add an external id - so i did.

What i didnt expect is that all data entered before the addition of the external id is not recognized by upsert. therefore any updates to those records - we have tens of thousands - will result in a duplicate record being created.

So here are two questions for the board:

1. how do i mass-update the old records so that they will appear to unsert?
2. how do i get rid of 4000+ duplicate records that may now have call history in them?

TIA!
Mike LeachMike Leach
Are the records 100% duplicate; including ExternalID, ModifiedDate, CreateDate, and OwnerId?

If at least one of these fields are different, then they can be uniquely mass updated/deleted via SOQL query.
JetlagJetlag
Hmmm - thats interesting. Yes good idea - I was unsure though about ancillary objects - will it refuse the delete if there are dependent child objects like tasks and cases?
Mike LeachMike Leach
That's a good question.

Lookup relationships would be safe from a Delete, but Master-Detail relationships would disappear as a result of the cascading delete.

Task probably has a native Master-Detail relationship, but Case should be a Lookup.

Do the duplicate records also have duplicate Tasks, Activities, and Notes associated with them?

Can a test Delete be executed on a single record via SOQL to observe the resulting behavior (and restored if it doesn't work out)?

I don't believe native sObjects can have multiple parent/owners, so the ancillary objects must either be dupes or have had their parentIDs changed.
JetlagJetlag
ive begun the deletion process and have been checking for tasks - and not removing any accounts with tasks - i'll write a little merge for those later or do it by hand if theres not too many left...

as to the cases - i actually hadnt thought about it too much but i was getting delete errors on some of my operations and i looked and each of them so far has had a case. so i think you're likely correct.

thanks for the insight.

before i was able to do any of this i exported all the ids of the accounts and ran through them all in 200-item chunks to make sure the new index "took"
benjasikbenjasik
What i didnt expect is that all data entered before the addition of the external id is not recognized by upsert

Not sure I get that.  When you mark a field as externalid, all the fields that are in the system will be recognized.

Can you post your case number so I can take a look at it?
JetlagJetlag
Case 00927771:API Creating Duplicates [ ref:00D062.50032ZbLU:ref ]