I am having the same or similar problem where the menu asks "delete this person?" I select "OK" and get the message "Cannot delete this person, please delete all connected relatives and try again." But, I don't WANT to delete the other relatives. Nevertheless, I tried it--went all the back to great-grandparents--and I STILL cannot delete the unwanted people.
I am having a similar problem. For some reason one person is represented three times. I try to delete one of the entries and I get the "cannot delete this person, please delete all connected relatives". The same person is connected to himself three times and therefor will not delete. Any suggestions?
Thanks for replying. I would send you the link but I used a "work around" solution and the problem is gone. I just went into Family Tree Builder and corrected the problem there, created a Gedcom file, uploaded it to create a new tree and got rid of the old tree.
My Heritage replied privately to my original message that this might be offered in the future if there was demand. I have GEDs with 36,000 and 23,000 names to merge - and removing over 1,000 overlaps manually is not practical, neither is mannually comparing and adding the data from those 1,000 overlaps, and then manually deleting them from one tree.
I hope that My Heritage looks at adding this soon, as I really don't want to have to learn another software package and move everything.
I am very grateful for a free program, but I would like to suggest that using the term "Merge" is a poor choice, If I have to go back and manually remove 100's of records it really is more of an "Add" feature.
I would love to see a true "Merge" function, but until you reach that point I would suggest you change it to "Add" to avoid confusion.
Wow, so this has been on the todo list for at least 3 years??
Btw, the reason why I've ended up with duplicates is because FTB itself has been creating them when I use the tree merge function. If the other tree is set for privacy over the living, FTB replaces their names with 'unknown' or '?', even if I'm a member of their family sites and I can see their full names on the screen. I hope, by this you don't tell me to take careful note of them and type them out when FTB is done messing things up, as MH does here: http://www.myheritage.com/help/2010/10/how-do-i-merge-duplicates-in-my-family-tree-builder-project/
I sure hope it doesn't take another 3 years to fix a problem the software itself has been creating.
I would like to address several points in your post:
1. Privacy: you merged a gedcom file into your project and found many individuals without firt names = privatized. This is not something FTB has done, these individuals were privatized in the gedcom originally. If you want to get a gedcom with all the names, you will have to ask the relevant site manager to send it to you, and this time choose not to hide living individuals.
2. You are correct in that FTB's merge trees feature does not resolve duplicates. To avoid problems with this in the future I would suggest merging smaller branches of the other tree, were you are sure all individuals do not exist in your tree already. Another option is to merge the information you are missing via Smart Matches with the other tree.
3. Our wishlist is very long indeed. We have many new features in mind and limited resources. But I can assure you that we are improving our product every day. For example we have just released FTB 7.0, with full support of Unicode charachters and full synchonization with the family site.
Thanks for the timely response, Noam, and for addressing my concerns. Unfortunately you didn't. Allow me to go backward in that order:
3. I am using FTB 7; the bidirectional sync is great and a much needed feature for a long time.
2. The tree merging function I'm using *is* in the smart matches process in FTB, and only merges one family unit at a time by design.
1. No, I didn't merge GEDCOM files, as stated above and in my previous posts I merged with smart matched trees via FTB.
Resources are limited everywhere; it's a matter of prioritization. A 'face cloud' is fancy trick, for instance, but far cry from being an essential functionality, like database (i.e. duplicate record) management. I'd suggest listening to your user base more closely (reading posts thoroughly includedp); they are your best salespeople.
When viewing a Smart Match, we will never let you see the first name of individuals that don't already exist in your tree with their full name. Otherwise users will be able to perform data mining on other trees, and breach the privacy of living individuals. There is a balance here between providing good research tools and protecting the privacy of our users.
The 'face cloud' is more than 4 years old. These days we are working mostly on historical records and research tools, but as I mentioned before I have sent your feedback (which I agree with) to our Product Team.
Thanks for the prompt feedback and support once more, Noam.
If that's the intention (which I also agree with), then this may be a bug. I did have the people with their full name in my tree before merging, hence why the new nodes with [unknown] names are their duplicates (otherwise I'd just have new nodes with partial names that weren't anyone's duplicate, get it?).
In the meantime, can I at least bulk delete the duplicates or am I supposed to delete them one by one?
Finally, on the point of smart matching and merging within a single tree, I get what the complexity is. Copying over an individual from one tree to another is one thing (technically not exactly a merger), and merging nodes and attachments within a tree another thing entirely. It's easily solvable, though, by first allowing users to merge the data (much the same way FTB already does across trees), and then eliminating duplicate attachments. Some spurious attachments may remain, but we (users) can then prune them aided by the tree inconsistency tool.
Besides, just imagine a user creating a new node on the tree for a person who's already there (perhaps s/he forgot to search first), and FTB responding: "this person already seems to be on the tree, would you like to merge this data with his/hers?" ;)
It is possible that your tree is in one data langauge, and the matched tree is in a different data language, even though the names seem the same. I sould have to take a look at the other tree to be sure. If this is the case, FTB should still be smarter and detect this of course. I will send you a private message so you can give me the details if you want.
You can try to delete the duplicates by exporting to Excel (via the Edit menu), deleting the relevent lines and importing back. Back up your project first.
One final note: FTB already gives a warning if you try to add an individual who is already in your tree. It may not catch all cases though.
I suspect the problem arises because the names are not exactly the same in both trees. The reason for it is that one of the trees doesn't have the spouses of the family unit members it's matching, so their last names don't carry over. Again, a smart match on those would resolve it. Failing that, the unmatched living individuals should come unticked by default, or FTB risks (mis)leading the user down the garden path. In any case, the match between these 'unmatched' ones would be picked up at their own smart match (if you catch my drift).
Hmmmm, I had the same question, wish there was a different answer. :)
Maybe in a future update you could use the same programing you have for the "compare" ability and be able to apply that to the people in a tree and then use the step by step merge to join the 2 individuals.
It would be great to search all my records and see if anyone is the same person, (found a few by accident, manually)