Family Historian User Group

Posted: **23 Apr 2023 15:50**

I've made the decision to perform an almost complete redo my database, instead of using the RM9 imported version. I have taken a copy of the imported data and removed all but the individuals, addresses and places. Because the individuals are untouched, the bare-bones facts are also still present. I'll likely remove all the facts before using AS to re-enter them by following the tree structure as a guide and copying data from my RM9 database. That should ensure that I have a "pure" FH7 splitter-style database with no artifacts of RM9.

Before I go further, I'd like to renumber the record IDs so that the root person would be #1. This should ensure that the actual root person comes up in the root position by default. Legacy Family Tree had the ability to swap RINs to achieve this. Based on what I've read, this is about the only time it's safe to do this type of re-organization, so I might as well do it now.

Can someone help me understand how to use the tools to achieve this?

Posted: **23 Apr 2023 16:27**

See Record Identifiers and the Procedure explains the process.

Posted: **23 Apr 2023 16:45**

... the root person would be #1. This should ensure that the actual root person comes up in the root position by default.

I'm not sure what you mean by the 'root position'. Do you mean the Focus Window? In FH you can change the file root at any time. This is independent of the record ID. If you leave the Tools>Preferences>Startup settings at their default then FH will open on the Focus Window with the root person. (The alternatives are to have it open on the last-used person, or to have it open on the Records Window instead of the Focus window).

Posted: **23 Apr 2023 16:54**

Thank you, Mike.
That worked.

Posted: **23 Apr 2023 17:00**

Lorna;

I knew about the "set root" option. Having the root person as ID #1 ensures that this happens by default. And; I assume that an export with the root as ID #1 would carry this behaviour forward to another system, if I send the data to someone. It's just something I figured I'd do now, as I certainly won't be doing another re-do anytime soon... Hopefully...

Posted: **23 Apr 2023 17:55**

Gary_G wrote: ↑
23 Apr 2023 17:00
Lorna;

I knew about the "set root" option. Having the root person as ID #1 ensures that this happens by default. And; I assume that an export with the root as ID #1 would carry this behaviour forward to another system, if I send the data to someone. It's just something I figured I'd do now, as I certainly won't be doing another re-do anytime soon... Hopefully...

So it's possible then to just renumber the individuals starting with the root? I'd like to do that.

Posted: **23 Apr 2023 18:28**

Teresa;

While it's possible to do it at any time, it can be risky under some circumstances.
That is why I tried it prior to a complete re-entry of my data.
I have removed all images, sources etc.
The risk of spin-off effects are reduced in my case.
If it's done any other time, make really sure you have a complete backup and check things well afterwards.

Posted: **23 Apr 2023 19:44**

The Record Identifiers article mentions the risks associated with renumbering.
It can upset a great many associated features, so it is generally not recommended, except when restarting from scratch.

Gary, most products treat the first Individual record as the 'file root' and that is what the Export Gedcom File plugin does.
It rearranges the GEDCOM details so that the FH File Root Individual record is exported first.

Posted: **23 Apr 2023 20:41**

In the case of a direct import the Record ID is maintained and does not automatically get set as the root person.
That was my case and I wasn't sure if setting it as root in FH7 would be a permanent fix, so I renumbered it.
Works fine and no harm done. That said; I'd only do it prior to a REDO.

Posted: **23 Apr 2023 21:07**

Thanks, Gary and Mike...I get it now...In an ideal world, I'd start over, but the reality is that's not likely to happen. No big deal.

Thanks again

Posted: **23 Apr 2023 22:57**

Gary_G wrote: ↑
23 Apr 2023 20:41
In the case of a direct import the Record ID is maintained and does not automatically get set as the root person.
That was my case and I wasn't sure if setting it as root in FH7 would be a permanent fix, so I renumbered it.

You are probably correct that in FH the first imported Individual record is not set as the File Root person.
I think FH is one of the few products that lets users explicitly set the File Root person.
Other products rely on the import order of the Individual records.

I'm not sure what you mean by "setting it as root in FH7 would be a permanent fix".
FH lets you reassign the File Root person as often as you wish and to whichever Individual you wish.
FH also lets you choose to reopen the Focus Window with whichever Individual was in Focus when FH closed.
That is completely independent of the File Root person who is made the Focus person by clicking the Home icon.

Posted: **23 Apr 2023 23:20**

Gary_G wrote: ↑
23 Apr 2023 17:00
Lorna;

I knew about the "set root" option. Having the root person as ID #1 ensures that this happens by default. And; I assume that an export with the root as ID #1 would carry this behaviour forward to another system, if I send the data to someone. It's just something I figured I'd do now, as I certainly won't be doing another re-do anytime soon... Hopefully...

I’m never sure what people mean by “person ID” but for some this means the XREF ID. The GEDCOM Standard specifically says that the XREF could be changed in the receiving program and to NOT depend on this being the same as was in the sending program. FH does change the XREF when it imports a GEDCOM!

I’ve never truly understood what the “root person” is! Maybe because I work in collaboration with multiple other genealogists that are generally my contemporaries living in other countries. But even if I was not, if I shared my database with others via GEDCOM they would surely have a different take on who was ‘root’!

Posted: **23 Apr 2023 23:51**

I'm not sure what you mean by "setting it as root in FH7 would be a permanent fix".

Mike;
Given that FH7 did not automatically set the first person in the tree as root upon database import, I wasn't sure that it would export that person as root if I set it from within FH7. If once it's imported and set as the root the change persists on export, then everything is fine. Either way the issue is permanently fixed.

Posted: **24 Apr 2023 00:04**

"KFN";

We speak about our family as a "tree". A "tree" begins at it root, a single point, and "branches out" as it grows. The "root person" of the "tree" in FH7 is the single person from which all others appear to "branch out". If you shared the tree with someone else, your "root" is still the same, unless the person adds some of your direct descendants. Sometimes a son or daughter might do this when they inherit a parents tree. Then, they might reset the "root" person to a single descendant of yours from whom all others now originate.

Now, one could get a bit more complex situation. That sometimes happens when, for instance, another person adds descendants to a person on one of your branches. This can easily happen when one builds out a tree for tracing DNA relatives. Perhaps this was what you were referring to with respect to sharing your tree. However; this is a special case and most people don't think of this as establishing a second "root" or a new "root". Both you and the other person each have what is considered a "root" person and the two are not the same individual.

Posted: **24 Apr 2023 00:41**

Gary_G wrote: ↑
24 Apr 2023 00:04
"KFN";

We speak about our family as a "tree". A "tree" begins at it root, a single point, and "branches out" as it grows. The "root person" of the "tree" in FH7 is the single person from which all others appear to "branch out". If you shared the tree with someone else, your "root" is still the same, unless the person adds some of your direct descendants. Sometimes a son or daughter might do this when they inherit a parents tree. Then, they might reset the "root" person to a single descendant of yours from whom all others now originate.

Now, one could get a bit more complex situation. That sometimes happens when, for instance, another person adds descendants to a person on one of your branches. This can easily happen when one builds out a tree for tracing DNA relatives. Perhaps this was what you were referring to with respect to sharing your tree. However; this is a special case and most people don't think of this as establishing a second "root" or a new "root". Both you and the other person each have what is considered a "root" person and the two are not the same individual.

I guess we differ in this, the database I work on has multiple starting points at the bottom, and multiple at the top. I collaborate with a third cousin in another country, and my wife does as well in yet another country. We all are “roots” as you say. This is not my tree, it is our tree with an extended root system!

When I need a report I must set the focus on a particular individual to get a their ancestors and dependents, which could very likely be a different dataset than mine.

When I say “share” I don’t mean “give” I mean that we share data, where someone that is my ancestor is also their ancestor.

Posted: **24 Apr 2023 01:27**

You have a rather complex tree then, "KFN".
Unfortunately; most genealogy programs aren't really set up to handle that type of situation very well.
They expect to have one person they call the "root".
Guess you'll need to keep switching the designated "root" to accomplish what you want to do.

Posted: **24 Apr 2023 09:40**

Gary_G wrote: ↑
24 Apr 2023 01:27
Guess you'll need to keep switching the designated "root" to accomplish what you want to do.

I don't suppose KFN ever needs to switch the designated file root. He probably doesn't use it for anything.
When you produce a report you specify who the report is about (e.g. ancestors of ...), and when you produce a diagram you specify the diagram root. Neither of these is the same as the file root, so it doesn't need to change. I don't think I've ever used the file root for any purpose.

Posted: **24 Apr 2023 09:44**

Lorna;

Clicking on the Home toolbar button takes one to the "root" person.
For me, this is quite useful and why I thought he'd have to change the "root" depending upon which group of people is being worked on.

Posted: **24 Apr 2023 09:59**

It depends how many people you have in your project. If it's a small compact group you might be able to navigate fairly quickly from the file root to another specific person, but if you had a few thousand people (and some users have tens of thousands!) you would probably work a different way.

One option which Mike and I have both mentioned is that your preferences can be set so that FH opens with the last-used person, instead of the file root, in the Focus window. Another option (which I use, because I like diagrams and the original versions of FH didn't have a Focus window) is not to use the Focus window at all. I use diagram-based edtiting, keeping a saved chart of whatever group I am currently working on. You can add people by 'drag and drop' in the diagram, and switch between their Property boxes by clicking on their diagram boxes. This is another illustration of how many different ways FH can be used.

Posted: **24 Apr 2023 10:02**

In FH the File Root person can be anyone you prefer and can be changed any time you like.
It is often not any particular tree root, but simply whoever is your current focus.
However, the most popular File Root is your own Individual record.
Then the relationship displays can easily be based on you, i.e. your grandparents, your grandchildren, etc.

KFN claimed that "FH does change the XREF when it imports a GEDCOM!"
I think it is true that FH changes the XREF initial letter from say P to I for Individual records on import.
However, I believe FH invariably retains the numerical part of the XREF so that the Record Id is maintained.
KFN may be thinking about File Merging of a GEDCOM into an existing Project where some imported Record Id may need to be changed to make them unique and avoid clashing with existing Record Id in the Project.

Posted: **24 Apr 2023 13:40**

I think the only time that I used the File Root was in my early days of using FH, before I learned how to easily navigate the records. I remember changing it according to which line I was researching.

My main FH project contains details of many family groups: the original line, those married/'espoused' into the line, plus their 'marrieds'/'espousals'. (I've worked on projects for various members of the family so have covered lines that otherwise would be of no interest to me.)

I understand that certain FHUG members use FH for a one-name study so, presumably, the File Root would be of limited interest to them. I'm sure I have read in FHUG that some others use it for other non-genealogical studies.

Nevertheless, the File Root can be set, changed, and used.

FH allows us to pick and choose, offering us many different ways of working, enabling us to feel comfortable in whichever way we choose.

Posted: **24 Apr 2023 15:50**

tatewise wrote: ↑
24 Apr 2023 10:02
KFN claimed that "FH does change the XREF when it imports a GEDCOM!"
I think it is true that FH changes the XREF initial letter from say P to I for Individual records on import.
However, I believe FH invariably retains the numerical part of the XREF so that the Record Id is maintained.
KFN may be thinking about File Merging of a GEDCOM into an existing Project where some imported Record Id may need to be changed to make them unique and avoid clashing with existing Record Id in the Project.

In my case this was not a merge but a new project, the entire value was changed. I imported a subset of my larger GEDCOM and the IDs were changed to be in sequential order. For example: Olaf in my import file was XREF I49, he was first in the file and set to I1. All the source_record XREF IDs were also change to be sequential, the first one found in the file was set to S1.

I expected this to happen as indicated in the GEDCOM specification!

Posted: **24 Apr 2023 18:05**

KFN, that is really strange because I have just repeated what you described and the Record Id of each and every Record type are retained perfectly.
When you say you imported a subset GEDCOM, exactly what did you do?
I am using the File > Project Window > New Project... dialogue.

Posted: **24 Apr 2023 19:32**

Yes, that is the thing I did.

The first item in the GEDCOM is a Family Record.

Code: Select all

0 @F8@ FAM
1 CHIL @I4@
1 CHIL @X4@
1 CHIL @I769@
1 CHIL @X49@
1 CHIL @Hello2@
1 _UID 8332153D9C8CD7119218444553540000F121
1 HUSB @I49@
1 WIFE @I48@

The above CHIL links are the only one in the GEDCOM.

1) I assume that the XREF is the same as the number in square brackets after the name in the Properties/Detail window! When I export to GEDCOM this conferms that the XREF is @I1@ !

Individual I49 (the first Individual in the GEDCOM file) is now in my FH database as I1, All Individuals are listed I1 thru I7.

Posted: **24 Apr 2023 21:43**

That subset GEDCOM appears to be derived from another genealogy product that allows arbitrary XREF names.
In that case, since there is no consistent XREF format, FH has no choice but to renumber records using its own format.

Most products use an XREF format of a capital letter to indicate the record type followed by a unique integer.
In such cases, FH always retains the unique integer as the Record Id.

For example, your Family record F8 should retain its Record Id as [8].

See FHUG KB Handling Renumbered Record IDs after Import which explains the rules.

Family Historian User Group

Renumber Record IDs as part of "RE-DO"

Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"

Re: Renumber Record IDs as part of "RE-DO"