FTAnalyzer questions.

[Bryman]

Having a residence and a census in the same year gives an error in FTA - one that could get annoying to have to check every time

Are you sure that you have identified the reason for the error and not just found a coincidence? I don't get FTA errors in such circumstances.

FTA does have an error in the identified line of your report. Some/all of the count given can actually refer to instances where there are census facts recorded without corresponding LC facts. Both counts are added in together.

 

[PK-KTK]

Yes, I am certain that when I have
Event: Census
Date: 1881
and
Event: Residence
Date: 1881
that I get that error

Here's why
Currently I have no errors in that spot


I'll find a random person who I have entered on LC for a census and duplicate their census entry and make it a Residence instead - thus giving them both a Census and a Residence fact for the same year.

And Bingo, I have an error

 

[PK-KTK]

The only way I don't get that error there is to Untick the "Treat Residence as Census Fact" which I'd like to keep ticked if possible but if that's the only way to avoid the issue then so be it

 

[Bryman]

The only way I don't get that error there is to Untick the "Treat Residence as Census Fact" which I'd like to keep ticked if possible but if that's the only way to avoid the issue then so be it

I think that Alexander will suggest that you untick the "Treat Residence as Census Fact" just like he did to me several months ago, possibly in this same conversation. He explained that this equivalence option was only put in place for use when census facts could not be adequately entered. You do not need it and that is what is causing you problems. Just one 'duplicated' record changes many of the error counts considerably.

You might be able to keep it ticked as long as there are no duplicated/overlapping dates for the Residence and Census records but why would you need to go to a lot of extra effort unnecessarily?

 

[PK-KTK]

Now that I've managed to resolve the 60 something errors I originally had in that spot, I probably will leave it unticked so that I can have a residence and a census in the same year - specifically for events like baptisms, marriages and burials.
And especially because often time where my folks are living, the only semblance of an address given on the census form is the town or village, not even a street to go by.
But it's taken this whole conversation to work out that what I was asking for was already there anyway.

 

[Alexander Bisset]

Just a comment for any Legacy users out there who might chose to enter an event once and then "share" it across the relevant people - this method does not allow for FTA to work properly.
FTA appears to not be able to see these shared events, and as such, even though you can see yourself that you have entered a census fact for the head and shared it to the rest, the rest of the family will appear to be missing that fact when running FTA

Hmmm not seen how Legacy creates "shared" events. Can you provide a sample GEDCOM of such a shared event. I may be able to add code to support this assuming its not too unusual from a standard GEDCOM format.

 

[Alexander Bisset]

The only way I don't get that error there is to Untick the "Treat Residence as Census Fact" which I'd like to keep ticked if possible but if that's the only way to avoid the issue then so be it

The "treat residence as census fact" option is really there for people who have imperfect trees where the census data has been entered as a residence fact and not a census fact. This is true of a lot of programs out there in particular it is true with the merge option from Ancestry's online tree to Family Tree Maker, even their latest version has this bug.

If you are correctly recording residence facts and census facts separately then there should be no need to keep this box ticked. It's only really there to help people who have a lot of legacy data in residence rather than census facts.

One other option if it is ticked is to use more specific dates. You should only encounter this error if the residence date overlaps the actual date of the census.

 

[PK-KTK]

Hmmm not seen how Legacy creates "shared" events. Can you provide a sample GEDCOM of such a shared event. I may be able to add code to support this assuming its not too unusual from a standard GEDCOM format.

Can do, and will do - how would you like to receive said Gedcom?

 

[PK-KTK]

The "treat residence as census fact" option is really there for people who have imperfect trees where the census data has been entered as a residence fact and not a census fact. This is true of a lot of programs out there in particular it is true with the merge option from Ancestry's online tree to Family Tree Maker, even their latest version has this bug.
If you are correctly recording residence facts and census facts separately then there should be no need to keep this box ticked. It's only really there to help people who have a lot of legacy data in residence rather than census facts.
One other option if it is ticked is to use more specific dates. You should only encounter this error if the residence date overlaps the actual date of the census.

Now that I've managed to resolve the 60 something errors I originally had in that spot, I probably will leave it unticked so that I can have a residence and a census in the same year - specifically for events like baptisms, marriages and burials.
And especially because often time where my folks are living, the only semblance of an address given on the census form is the town or village, not even a street to go by.
But it's taken this whole conversation to work out that what I was asking for was already there anyway.

I had residences thanks to the Ancestry-FamilyTreeMaker issue - I've since been able to largely remove the pertinent census year problems, and am working on the other residence/census facts to get them all to census

 

[Alexander Bisset]

Can do, and will do - how would you like to receive said Gedcom?

I've sent a private forum message (check your forum inbox top right of this page) with my email address.

 

[Alexander Bisset]

Hmmm not seen how Legacy creates "shared" events. Can you provide a sample GEDCOM of such a shared event. I may be able to add code to support this assuming its not too unusual from a standard GEDCOM format.

I've now had a chance to have a look at the file, sorry for the delay and the time its taken I've been exceptionally busy. My findings are that it's a totally custom format used by Legacy. Sadly Legacy often seems to adopt non-standard formats. Instead of simply internally storing the information in the database and exporting the data using the GEDCOM standards, they have instead chosen to export the data using their own non standard custom tags. It would have been trivial for them to export the data adding the extra facts to the other individuals that the fact is shared with and exported the data in a fully standardised GEDCOM format. However for some bizzare reason instead of the data export being standardised they choose to add custom fields.

This sadly makes support considerably more difficult. The problem is that the data has got specific definitions that may vary from installation to installation. The best I think I could achieve is with CENSus facts to look for a _SHAR tag and add the census fact to the other individual. My problem just now is that the program loads an individual then adds the facts for that individual before moving onto the next person. The shared fact could therefore apply to someone who hasn't been loaded yet so it would find a shared fact and then not find the person to add it to. So I'd need to write something completely new to search for shared facts in the file after all the individuals are loaded.

The practical upshot is that this can be a wish list item and I will look to add it at some time in the future but its not at all a quick fix. Sorry.

 

[Bryman]

V5.0.1.4 recognises census references from Notes but there still seem to be some problems with 'Lost Cousins' and 'Colour Reports' tabs.
Should references found in Notes be used in all reports?
Some notes are being ignored and what works for 1841 (yellow tile) does not work for 1881 or 1911 (orange tiles)!!
It is late so I don't have time to give full details now but will raise an issue, with Gedcom, in the morning unless you notify that problem has been corrected.

 

[Alexander Bisset]

Ok I'll await your issue as I'm not sure what the nature of the problem is.

 

[Alexander Bisset]

Just a comment for any Legacy users out there who might chose to enter an event once and then "share" it across the relevant people - this method does not allow for FTA to work properly.
FTA appears to not be able to see these shared events, and as such, even though you can see yourself that you have entered a census fact for the head and shared it to the rest, the rest of the family will appear to be missing that fact when running FTA

BTW version 5.0.1 now includes support for Legacy shared facts. Let me know if its properly working. I don't use Legacy so there is a chance there is some issues to be ironed out still.

 

[Bryman]

Ok I'll await your issue as I'm not sure what the nature of the problem is.

Issue 13555 now raised and mini Gedcom file attached with data to illustrate concerns/questions, using v5.0.1.5 of FTA.

 

[PK-KTK]

Is there some way of telling FTAnalyser who the root person should be if it picks the wrong person (for some reason?)

 

[PK-KTK]

BTW version 5.0.1 now includes support for Legacy shared facts. Let me know if its properly working. I don't use Legacy so there is a chance there is some issues to be ironed out still.

It would appear on the surface that it does indeed work.
Will have to look at it in detail in a week or so, have a death in the family to deal with right now.
Please nudge me for a reminder if you've not heard back from me by mid-May in regards to the shared facts.

 

[Tim]

Is there some way of telling FTAnalyser who the root person should be if it picks the wrong person (for some reason?)

FTAnalyzer uses the root person that you selected in your Family History Software (FHS) program, so FTAnalyzer doesn't technically pick any person.

But you can change the root person in FTAnalyzer by going to the individuals tab, right clicking on a person and selecting "Set as Root Person".

You will need to do this every time you open FTAnalyzer unless you make it permanent by changing it in your FHS.

 

[Bryman]

I was investigating a problem in one of my trees using v5.0.2.0 when I was informed of a new level, v5.0.2.1, which I downloaded.
That seemed to cause more problems so I raised issue 13570.
Now I notice that there is a further bug fix level, v5.0.2.2, available. However, the list of updates and bugs fixed goes back several minor levels.
Please can you indicate what the changes are for each release so that users who try to keep up to date can easily identify whether the changes may be relevant?

 

[Tim]

Hi Bryman,

I add all the updates and new releases to its own special page in the Documentation section on the codeplex website or you can go directly to the page here.