8 replies to this topic

[Emile Nucho]

Hello, 

 

I have two different and separate family trees (X FAMILY) and (Y FAMILY). On the other hand these two families are related through a Grand-mother. My question is: can the data of X be merged with Y? If so, how, please.

 

Many thanks,

 

Emile Nucho

[zhangrau]

Click on Help in the menu bar, select Search, type in "merge," and from the selections pick "Dragging and dropping people"
 
There are also webinars available at http://www.rootsmagic.com/Webinars/

[Vyger]

Yes and in my opinion it would be much better to do so.

 

1. Make sure all your facts are marked for gedcom export, Lists > Fact Type List (look in right hand pane for each fact type and edit it necessary)

 

2. Export all individuals from either X or Y database selecting "everyone" and checking all the boxes down the left hand side of the gedcom export selection.

 

3. Open the other Database, import the gedcom created in step 2 selecting Combine into this Database.

 

4. You will find the common grandmother twice in the new combined database, simply merge these two individuals.

[Jerry Bryan]

Just one more suggestion to go with the excellent suggestions above. Suppose you have database A and B. Don't drag and drop A into B and don't drag and drop B into A. Rather, create a new database C and drag and drop both A and B into C. Merge the common grandmother in C and declare C to be the new, combined database. That way, if anything goes wrong, you still have database A and B to fall back on for any needed do over.

 

Jerry

[TomH]

When you drag'n'drop from one database to another, there are some losses. In addition to what vyger said about fact types, any problem flags and quasi-duplicates from previous merges that have been marked as "not a problem" will reappear.

[Vyger]

Jerry or anyone,

 

How does Drag&Drop work with RM specific items such as Shares?, I was never quite sure, never tested it and therefore never completely trusted it. If To-Do,s, Correspondence and Research Logs are an issue in both or either I don't believe Drag&Drop would work.

 

One final point which I have made years ago regarding Drag&Drop, I believe restrictions within Fact Type regarding gedcom export should not be applied when using Drag&Drop and all information should be transferred by default. Why?, because restricting, and therefore dropping, information between your own databases does not make sense to me and I can't see why someone would want to do so.

[Jerry Bryan]

I've tried and never quite succeeded in producing a comprehensive list of all the glitches that you might encounter with drag and drop. I think the only acceptable number of glitches should be zero, but RM is not at the zero defect level on drag and drop. Of course, some of the "glitches" are sometimes viewed as advantages. In any case, we have to remember that behind the scenes, drag and drop is a GEDCOM export and import which automatically includes RM extensions to GEDCOM. That being said, here is a list from memory.

1. Drag and drop goes by the GEDCOM options on which facts are exportable or not. There is no "drag and drop all facts" option. To avoid losing facts, you have to go into Lists->Facts and turn on GEDCOM export for all your facts and then go back and turn off GEDCOM export for any facts that you want to leave turned off. There is no warning about lost facts.
2. Trailing carriage returns in notes are lost.
3. Description fields longer than some limit - maybe 72 characters or something like that, I don't remember the exact number - are truncated.
4. Some DNA data is lost.
5. Unused places, sources, user defined facts, and user defined source templates are lost. This is often used cited as an advantage rather than as a glitch.
6. User defined source templates become duplicated rather than being put back together properly. The net result is that Master Sources which use user defined source templates do not merge correctly.
7. Color coding is retained, but Named Groups are lost. Similarly, the Set Relationships indicators are lost.
8. "Not a problem" indicators are lost.

I don't use shared facts, but i believe that when I played with shared facts and drag and drop that they exported correctly. I could certainly be wrong about that. If shared facts don't drag and drop properly, that would be just one more in a very long list of reasons not to use them.

 

I don't use RM's to do list or correspondence logs. I do use RM's Research log. I haven't tried a drag and drop to be sure the Research Log is handled correctly.

 

Jerry

[TomH]

I think 100 chars is the limit for importing event descriptions. Shared events are preserved. Don't know about To Do and Research Logs.

[Laura]

ToDos and Research logs that are linked to a person are transfered. General ToDos and General Resewrch logs, General Addresses and unlinked Repositories are not. I don't think a Correspondence list is either as the items in the list are not linked to a person.

Shared facts transfer in a Drag and Drop as Sharees are linked to the Principal.

My personal rule of thumb for Drag and Drop is, if it is linked to a person or an item like a Repository linked to a source which is linked to a person, it will be transferred in a Drag and Drop.