Family Historian User Group

This morning when opening FH, I received the following exception report:

---------------------------------------------------------

Record Type=Individual. Gedcom Id=I1619. Record Number=1594.
l.77868 - EXCLUDED: invalid (exceeds max) : "1 SEX M"

---------------------------------------------------------
The numeric portion of Gedcom Ids have been retained as Record Ids. Use these to match entries to records.
---------------------------------------------------------

I validated the file, and it reported no errors. I have since closed and re-opened both FH and the affected project several times and no further errors have been reported.

Am I right in thinking that the record number (1594) stated in the exception report relates to the record ID of the individual concerned? If so, she is still present in my file, her sex is correctly shown and all relevant facts and sources appear to be present. I have not edited her record recently.

Or does the Gedcom Id "I1619" relate to the individual record? That would make more sense, as the person with the record ID 1619 was entered earlier this morning. Initially I entered their sex as unknown, as the information was obtained from an online tree in which the individual's sex was not apparent, and only their last name was referenced. I then changed their sex to male having found further information from another source. They are still recorded as male in the records window and the property box.

Based on the above message generated by FH, is there anything else I should be concerned about, or ought to check?

It sounds as if you managed somehow to get two sex fields. I gave it ago, but could not quickly reproduce the problem. FH sounds to have fixed the file, so unless you or someone else can workout how to reproduce it I would not worry too much.

The report is referring to the Individual record with Rec Id 1619.
That is the 1594th record in the GEDCOM, due to 25 gaps in the Rec Id numbers.

It seems to be saying that as a result of your editing both a 1 SEX U and 1 SEX M line existed at line number 77868.
Only a single 1 SEX line is allowed per record, so the illegal line 1 SEX M was deleted/excluded.

So I would have expected Rec Id 1619 to be recorded with Sex unknown, but you say it was Male.

It might be possible to review the saved Snapshots of the GEDCOM file to see if that double 1 SEX entry can be seen.

Maybe entering another new record and setting the Sex as you did before might recreate the symptoms.
If so, then that needs to be reported to CP.
It might be worth reporting that exception anyway because clearly something went wrong with the edit.

Thank you both. I have been out most of the afternoon, but will do some investigating and report back. At least I gather that it seems to have been a fairly simple error that is unlikely to have caused any longer term detrimental issues with my project file!

This is the relevant section of the project gedcom that was saved as a backup after adding the individual and before closing FH (line numbers reproduced from my text editor):
-----------------------------
77865 0 @I1619@ INDI
77866 1 NAME Unknown /McCaw/
77867 1 SEX M
77868 1 SEX M
77869 1 FAMC @F563@
77870 1 FAMS @F565@
77871 1 CHAN
77872 2 DATE 12 OCT 2021
77873 3 TIME 11:39:51
------------------------------

And this is the same section as it now exists following the exception report generated when the project was next opened:
------------------------------
77865 0 @I1619@ INDI
77866 1 NAME Unknown /McCaw/
77867 1 SEX M
77868 1 FAMC @F563@
77869 1 FAMS @F565@
77870 1 CHAN
77871 2 DATE 12 OCT 2021
77872 3 TIME 11:39:51
-------------------------------

So it's clear that two identical lines existed for 1 SEX M - no trace of a line for unknown sex which was the initial state of the individual when I first entered him in the project. It appears that two identical lines were generated somehow when or after changing the sex from unknown to male.

I have experimented with the same scenario several times both in this project and the sample project, but have been unable to replicate it. I'm not sure in the circumstances that reporting this to CP is going to achieve anything, as when I have reported issues previously that have only occurred in limited or specific circumstances I have been asked how to replicate them, or to demonstrate the occurrence, and so far I can do neither.

It still might be worth reporting with a description of the sequence and they may discover by inspecting the program code that there is a fix. Include a reference to this thread or those screenshots.

Ticket #987416 refers. Noted and passed to developers for review.