* Splitting off roots into new databases

[Tykelaw1]

As I have progressed in my family history research over the years, I have, I guess like most people, ended up with other lines through the female names. In my case Battye (Yorkshire), Brewster (India), Churcher (Hampshire), Savigny (India). In total that comes to a lot of people (especially the Battye's, my grandfather was the eldest of 12, all of whom survived and most had kids).
Rather than start a new Family group for each of the above lines and re-entering all that data again (with all the errors that might crop up), is there an easier way in Family Historian V6 or 7 of doing this? I could cut & paste, but there are lots of individuals and it would be very time intensive.

Thanks, Graham

[Gowermick]

The general perceived wisdom is not to split your project, but to keep the groups together in one big tree. There is always the chance that inter-marriages took place in the past, and having a single tree avoids duplication of individuals and so keeping the different trees in sync.
You’ll find no advantage in splitting your tree, and with judicious use of custom ID’s, you can readily see which tree/branch each individual belongs to.
e.g. Brewxxx, Churxxx, Savixxx etc.

These custom ID’s can then be used as filters for reports, charts, queries etc

[dewilkinson]

I completely agree that it is not best to split your database. An alternative thought is to create a Flag for each branch and you can customise the Property Window to show them (as I have done for different reasons - see image) which makes it easy to maintain them. Also, you can set them (or clear them) en bloc automatically using a query and the clicking the cog wheel.

Capture.JPG (130.75 KiB) Viewed 2093 times

[tatewise]

Welcome to the FHUG Graham.

That sort of question regarding splitting a family Project into separate Projects for various branches is often asked.
The answer is always the same ~ Don't do it unless you have an extremely good reason.

FH has many ways of distinguishing the different branches as others have mentioned.
In addition to Custom Id and record Flags, there are Namd Lists and functions such as =IsAncestorOf(...).
FH is very good at managing Projects with many thousands of records. We can give you tips if needed.

If necessary when required, it is relatively easy to create temporary sub-Projects by exporting branches, but the reverse of merging multiple Projects back into one Project is far more tedious.

[Mark1834]

I don't necessarily agree that it is bad to split trees. That should be a case by case decision, and there may well be good reason to do just that. I have separate trees for myself and my wife, as we were born and grew up hundreds of miles apart. There is no credible risk that they overlap in the timescale of interest.

There is almost a challenge there - conceptually, I can see how they can be combined in the future relatively easily with a dedicated plugin if that becomes necessary, but I agree it would not be simple to do manually. But that's for another day...

[tatewise]

Mark, with such a split the File > Merge/Compare File... command will bring them together, but may need some work on merging Sources, Media & Places. It is unlikely to need a Plugin.

Presumably, you have to duplicate your children and descendants and their spouses' immediate ancestors in both Projects?

[Mark1834]

Yes, I was initially thinking of a very simple plugin to handle duplication of any common individuals or lumped sources, but by the time I got back from our lockdown permitted dog walk exercise in the sunshine, I’d decided it would be quicker and easier just to delete duplicate individuals (only 3) first and use the built-in tools. I’m strict in using identical naming conventions in all trees, so you wouldn’t see the join!

It’s purely hypothetical, as I won’t be joining them anytime soon, but it’s worth remembering that merging trees that don’t overlap is fairly straightforward. I did something similar in the FH7 beta trial - live research on an obscure Irish branch of the family that had no overlap to avoid risking my main database that I can merge back in later if necessary.

[tatewise]

Assuming the duplicated Individual records have similar details, it would be better NOT to delete them.
They form the synchronisation glue that automatically join the two branches together in the Merge/Compare File command.

Clearly, merging two trees that don't have overlapping Individuals will just form two distinct Relationship Pools.
However, you still must review Source, Media, Place, etc, records especially if you use lumped Sources.
Otherwise, you may get duplicated Source, Media, Place, etc, records.

You did not explain whether you have to duplicate your children and descendants and their spouses' immediate ancestors in both your current split Projects?