No efficient way to merge new FamilySearch tree to existing RootsMagic10 tree?

I have a RootsMagic10 tree that has about 5 generations in it. It also has people that are not part of my direct ancestor tree (EX: cousins). I used the AutoMatch feature to merge it with FamilySearch. Now I would like to add additional new older generations to RootsMagic from FamilySearch. After running a small experiment and researching online, I see that using the RootsMagic Share data function to import a tree from FamilySearch does not do a good job of merging with the existing RootsMagic tree; for instance it will create new duplicate person entries. I also read online that the tree import may actually stall or halt in its attempts to import.

A method to work around this is to add the new persons one by one in RootsMagic, and then sync with FamilySearch one by one. This would be tremendously time consuming to add a large tree of older generations.

Another work around would be to start over in RootsMagic with the import of a new tree from FamilySearch. That would have the disadvantage of only having the direct ancestor line from FamilySearch, and would require manual entry of all the other persons that I have in my existing RootsMagic tree.

So am I missing something, or is it the case that there is not an efficient way to merge a large new FamilySearch tree to an existing RootsMagic tree?

Download from FamilySearch into a separate blank database. Then trim that tree to only include the people that you want. After that you can use drag n drop to add them to your main database.

2 Likes

I am not sure your exact goal. You may also get some comments about downloading all info from Family search without review.

One way might be to download different branches from FS into own database then combine later into one. The “trick” would be to minimize overlaps without skipping people . You will likely have to cleanup afterwords. I can not speak on the best way to implement that method but maybe someone else has so they can advise on what they learned if they have done.

Kevin

1 Like

Big imports are slow, but I don’t recommend those anyway, because you don’t see what you get, and may download a lot of messy connections and data.

OTOH, when you restrict the number of generations, it’s perfectly possible to add a few generations to an end-of-line person in your current database, as long as you are aware that you may need to do a manual merge for that person, and some close relatives.

Thank you for the replies. I am importing from FamilySearch into a new RM file. It’s a big import (10 generations), and as advised, it is taking a long time. Once it finishes, I will try drag and drop to merge into my existing RM file. Is there any merging capability when using drag and drop? How well does it work? So if for example I want to add some more ancestors to a end of line person in my current RM tree, and I drag a tree that starts with that same person from my new RM file that is the “big” FamilySearch import, will RM give me the opportunity to match that end of line person, and then merge, or ?

If you drag’N’drop that same person, from your new RM file that is the “big” FamilySearch import, RM will give you the opportunity to match that end of line person only and I believe you’ll need to use RM’s merge tools to effectuate merging any others that are part of the drag operation.

Here’s another thing:

If you import ancestors, RM will also import their siblings, and AFAIK, you can’t switch that off. And on FamilySearch, you will often find duplicates there, so it can help to let RM merge duplicates in the downloaded tree, before you transfer this to your work tree.

Also, if you only want ancestors, not their siblings, you may want to do a selective export that includes the root person’s ancestors only. That is only available for GEDCOM in RM 9, but I hope that you can do that in RM format in RM 10.

Instead of merging into your working file, try making a copy of your working file—give it a slightly different name such as Smith with Familysearch-- then do your drop n drag into the copy–as there is no UNDO --that way if it doesn’t work the 1st time, you are still okay and can try another copy a second way–once you figure it out-- then do it in your original or just use the copy…
drag n drop is a very powerful/ wonderful tool BUT can end up all messed up —so make sure you have a back-up of your original file…

1 Like

If the same person is in both files then drag them from one database and drop them on top of the other. Check the box at the bottom that they are same person. It will merge them and continue the line. Just watch the option you select in the drag n drop.

Just a “heads up” that RM9 drag’N’drop has a > Let me select people from a list “option” too (just like GEDCOM) and can be used to selectively mark and unmark groups of people or individually checkmark some, for inclusion in the drag operation.

2 Likes

I would also Color Code the FS people so you know which ones they are. Can always clear the color.

1 Like

Thanks again everyone for your help. A reminder of what I am trying to accomplish: I have an existing RM tree/file that is my working tree that I have good confidence in. I did a sync of that working tree with FS. (which does not add people to an existing RM tree/file) I now want to enlarge the working RM tree by adding older ancestors from FS. I have another RM tree that I created by importing a fairly deep ancestor tree from FS to RM. I am using the drag/drop process in RM to enlarge my RM working tree.

Some details about the drag/drop FROM one tree/file TO another tree/file that others may find helpful:

  • When a merge is done for the person you dragged/dropped (when you check the optional same person box), if there are ancestors of that person (and you selected to include ancestors) in the tree you are dropping into, merge does not happen for those ancestors , instead a new person is added. So probably the better approach is to only drag and drop into an end-of-line person. Note that even when dropping only to an end-of-line person, if the TO ancestor tree already contains someone present in the FROM tree, that person will not be merged in the TO tree, rather they will be added. It would be a very useful enhancement for RM to flag potential duplicates and offer to merge for all of the potential duplicates in the TO tree, instead of just the initial target person. In the meantime, it is a very good idea to run the duplicates merge utility (with the sounds alike option selected) on the TO tree after the drop completes.

  • After the drop concluded in the TO tree/file, RM10 did not immediately update the currently displayed pedigree chart. I had to click around before the pedigree chart included the changes from the drop.

2 Likes

My reaction to this question is that it is good this process is difficult because entering large amounts of unproved data to one’s carefully researched data does nothing positive. I do personally use data from FamilySearch but only to travel back one generation, one person, at a time which is the cardinal rule of genealogy research. There is an amazing amount of useful information on FamilySearch, Ancestry, Geneanet, etc., BUT there are many, many errors in all of these databases. It pays to process the information you take from the work of others one person at a time.

I recommend matching your current database with FamilySearch. Then look at your matches and go back in time using the furthest back in time ancestor, and see if parents, siblings are available there. Look at the quality of what is on the match and choose whether you want to add what is there to your database. I personally own some vital records sources, so I try to check out whether the family I am copying information from is likely correct. If I can verify some facts by vital records I feel more comfortable using information that I am unable to verify.

1 Like

I take your point about data quality. My current goal is to obtain a good local backup of a substantial online tree. This way if the online tree goes away for any reason, there is a local copy. There are of course capacity limits for how large your local database can be. Scrubbing the data and updating the tree as needed can happen over time, as it must for a large tree.