Jump to content


Photo

Merging Roots Magic files

mege gedcom

  • Please log in to reply
5 replies to this topic

#1 AlJones

AlJones

    Member

  • Members
  • PipPip
  • 10 posts

Posted 12 December 2015 - 12:52 PM

My choice of the word "merge" is going to upset some purists (shoot, it bothers *me*!) but here's what I'm trying to do and would appreciate some thoughts or assistance.
 
My "Family" data set is, obviously, those people who are direct line ancestors with often some offshoots to "twice removed" but I try to limit the 'out of direct line' folks.
 
My second file is a "one name" project.  Basically, I have brought / am bringing all verifiable information on the "van Amber" name into one project.  Most of the information is coming from census data (thank you FamilySearch) or the SSDI.  An internet search has also lead me to some stat / provincial birth / death / marriage data which I've also included.  Since 'van Amber' is also in my direct line, I'm finding that I have considerably more information in the one-name project for some individuals than I do in the 'family' project.
 
It's beneficial to note that almost all of the van Ambers to be found in the states are related so most of the people I've found can fit into my tree, though often further removed from the main line than I'd wish.  I can live with this.
 
The question now becomes "How can I combine the information found in the one-name project into my family project?"

  • Obviously I can manually go through each list and selectively, manually enter the missing data.  If I do this, I'm going to miss copying people or data from people - I'm human, I know I will.
  • GenMerge and it's ilk are a useful tool if I'm wiling to allow non-controlled merging - that's not going to happen.  Add to that, GenMerge doesn't support the CENS gedcom tag and much of my information is derived from the census'.
  • I've seen references to "drag and drop" in another thread but I don't see any references to what they're trying to drag and drop.

I'm going back to continue work on the one-name project, but would be interested to know how others have solved the challenge of having related data in two data sets (or GEDCOM files) and combining relevant data.



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 12 December 2015 - 03:14 PM

However you go at it, plan on experiencing lots of problems and work to clean things up. RootsMagic has a couple of tools that you should try out with copies of your databases so that you can choose what works best for you.

 

File > Compare files looks for commonalities among people in the two databases and then you can choose and transfer facts or people from one to the other. There may be too many pairings for you to handle given one database being a one-name collection.

 

Tools > Duplicate Search Merge looks for commonalities among people in the same database. You choose which person is Primary and then merge everything from the Secondary into the Primary.

 

Drag'n'drop between databases: you line up the Pedigree views to have the common person in view in both and drag'n'drop from one to the other. You are asked if these are the same person and what other people you want brought over.

 

None of these methods are perfect. You won't get spousal facts with single person transfers. The slightest difference between a fact, source, place (and even sometimes nothing we can detect) can result in duplications of them. You could compare Place Lists and harmonize them before you start any transfers to preclude proliferation of almost identical place names. But the effort may be no less than merging places afterwards.

 

It does make sense to me to consolidate so that there are not two datasets to maintain when there is information common to both. The downside would be if the dataset gets so large that the program becomes objectionably sluggish. AFAIK, that is an issue with FTM above about 1,000 people on my computer. RM does not become draggy for me until you get up to tens of thousands. Of course, much depends on the quantities of facts, sources, ... and what it is you are doing. You can create a named group of your family people to help when you are wanting to focus on them.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#3 AlJones

AlJones

    Member

  • Members
  • PipPip
  • 10 posts

Posted 12 December 2015 - 03:44 PM

Thanks Tom.  I'll be looking at two out of the three shortly.  I already check occcasionally to make sure I don't have dupes in my mess.

 

I wasn't aware of the drag and drop feature which looks most interesting - here, let's see about reality. 

And the comparison between data sets! Oh my, that could indeed prove interesting.

 

Just for the odd note, the 1918 draft registration cards are proving most interesting!



#4 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3406 posts

Posted 12 December 2015 - 07:30 PM

My choice of the word "merge" is going to upset some purists (shoot, it bothers *me*!) but here's what I'm trying to do and would appreciate some thoughts or assistance.

 

Personally I decided to move to one master database some years ago and would not reverse that decision. Working with separate databases will create differences in the way Sources, Places and other data are recorded through natural human choices.

 

I believe it is being recognized that Rootsmagic and other desktop software do have development needs to better facilitate users of large databases in working with subsets of that database. Personally I have foune much more benefit from working with one master database than in the past trying to work and maintain several smaller databases.


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

User of Family Historian 6.2.7, Rootsmagic 7.6.0, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#5 AlJones

AlJones

    Member

  • Members
  • PipPip
  • 10 posts

Posted 13 December 2015 - 12:11 PM

Vyger, in general I completely agree with that.  I am also working on my half brothers' family - dad married three times - amd after playing with PAF in separate files, I too, decided that one single file was better. 

 

In this case where there is little commonality - a very small percentage overlap (in fact only three out of about 500 people!?! so far) - that having the extra van Amber's 'running around' my family file would be more hassle that it would be worth, I think.  In the long run, I don't know - yet. 

 

Actually there are considerably more than the three, it's just that there isn't enough common information for RM to consider them duplicates yet.  That was a surprise since I know there are more but when I looked at a few, the census data from ONP isn't in the family (again, yet) and the birth dates / locations in the family file are more complete than many in the ONP. 

 

Now to go separate my two Isaacs - one born in 1839 the other in 1840 both in the Civil War, both born in Jefferson county, New York - one eventually moves to Minnesota - Sheesh!!!! (this in my One Name Project)



#6 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1513 posts

Posted 19 December 2015 - 02:17 AM

Just my opinion....

I keep all of my research in a single database. I've done research & reports for family and friends and sometimes just to indulge my personal interests in historical personalities. My database has been growing since the late-1980's and is now approaching 400K individuals. They are in approximately 17K separate trees, because MANY of them are single-person trees, waiting for me to find more info and link them to one of my "main" branches. The tasks which take longest are those involving an index re-build. I run the Database Tools often (daily or more, depending on the types of data entry or merging that I'm doing).

 

How cool is this? Well, I now can show in the Relationship Calculator that one of my brothers is related to his wife at least 49 different ways (the closest being ninth cousins). If I were managing multiple trees, would I be able to say that?