I thought that importing a tree from a GEDCOM file would create a new and separate tree and open it side by side with my existing tree which was already open when I did the import. However, a separate tree was not created. Instead, all imported data was added to my already open tree which is not what I wanted.
During the import, there were no dialogs or prompts asking whether any individuals were related or the same, so I presume none of the imported people were linked to any of the existing people in the database, but I now have duplicates of many, many people.
I want to remove all data that was imported. I closed the file without doing a backup, hoping that by doing a restore from a previous backup would remove all of the data that was accidentally imported from the GEDCOM file. However, after the restore was completed, I can still find the duplicates that came from the GEDCOM file.
Iām thinking that what I should have done was to import the GEDCOM file into a new, empty tree and then open both trees side by side and carefully merge data from one to the other.
Iām looking for any suggestions on how to clean up and remove all of the imported people & data. I welcome any help or suggestions.
whatever way you go about this ā make sure you have backups
Within RM UI the DateEdited field might work
You might be able to create a group based on Date edited (assuming the date was updated to when added to RM).
then delete those people (after reviewing or removing anyone you want to keep) ā there are a few more ways
This really cannot happen the way you describe. A backup is a āpoint in timeā transaction. Itās not possible for changes made after the backup to appear in the backup file (unless someone manually edits the zip file). Assuming the backup was made prior to the gedcom import, either you werenāt really looking at the restored file or the duplicates existed prior to the gedcom import. You might want to try restoring an earlier backup again and double checking.
If you really canāt find a backup from before the import, there may be another trick, and thatās a selective export of all people connected to a person in the original tree. I never tried that, but when you do an export, you can select people from a list, and in that selection, you can mark all persons in the tree of a highlighted person.
This trick depends on the assumption that in your original file, all people are connected, and that in the menu, the phrase āin the treeā means people connected to the selected person. The imported people form another tree, unless you merged one duplicate already.
You can then import the exported file into another one, and check the results.
Thanks for your prompt replies.
As suggested I created a group with Date Edited, then deleted everyone in that group and everyone who was imported from gedcom file was deleted.
Good suggestion, thanks!
Before deleting everyone in the group I ran the āCount treesā tool and saw that the imported tree had 314 entries, but when I ran the Delete Everyone in the Group it reported that 315 entries would be deleted.
Shouldnāt the number deleted be exactly 314 as reported by the Count Trees tool?
Leo
kevinm: I canāt explain how the imported people were still present after restoring from a previous backup. Could it have been that in āProgram Settingsā the option āOpen last database when starting RootsMagicā was enabled?
Restoring a Backup does two things. It deletes the current leou.rmtree and then re-creates the ādatedā old leou.rmtree (unless you specify for it to be created in a different folder than the current one). Thatās why kevinm inquired.
If you wanted to ensure the group was of everyone in the same tree, under Mark select āEveryone in highlighted personās treeā. Otherwise, the count was probably off because someone outside of that tree was edited.
As a recommendation, use the option on backups to append the date. I keep a backup for each day I work in RM for a month, Plus one back per month going back a year. May sound a bit extreme but itās saved my bacon a few times when Iāve hit flaws in RMās DB or RM bugs, and of course, situations like yours.