Family Historian User Group

Just starting to take a look at this plugin.

I spent a little too much time not long back changing a lot of baptisms to christenings.

The records were for baptisms, but the software I was using would not use a baptism fact as a birth proxy in the views. (A baptism was hard to see until you looked at all the facts. It was just one of many.)

This particular software did use christenings as a birth proxy. So a family for whom I only had baptism records, I recorded them as christening facts so I could see the info in the vitals screens. (And I had a feel for when they were born.)

Family Historian will show baptisms, christenings, and burials as birth and death proxies, which is nice.

From wikipedia: 'In some denominations, baptism is also called christening, but for others the word "christening" is reserved for the baptism of infants.'

Now I want to correct that. Change Any Fact suggests I have 430 some christenings and I suspect most should really be baptisms. Most, but maybe not all, reflect a good proxy for year of birth. (I only have one adult baptism that I recall. The individual was baptized and died the next day.)

I typically try to record the text of the record in the source entry for the fact. So I can see, from the source, often times, if it's really a baptism.

Is there the possibility to provide that source data info on the confirm edit screen perhaps?

Name:
Data:
Source: (granted, there might be several)
Option:

Is that a possibility?

FYI: In FH & GEDCOM not only is there Baptism and Christening but also Christening (adult) events.

I think that would be a lot of work just to cope with one task, and you would still have to eyeball each one to decide whether to Change or Skip.

So perhaps there is another way based on the Individual Name and [RecId].
Could you create a Fact Query that identified which Individual records do (or don't) need to change. It would have a Rows filter to check Source details according to your criteria.

Then armed with a list of Individual Names & [RecId] those are what you eyeball on each confirmation.

I made a query

Query Type: Individual

Columns:

Individual, %INDI% -Name
Record Id, =RecordId() -Their Id to sort on (like the plugin does).
Where Within Source, %INDI.CHR.SOUR.PAGE% - I've got notes here.

I can't put my figure on the expression of the "Text From Source" expression. I need that since I have more notes there.

Rows:

Exclude if... %INDI.CHR[1]% is null.

The result set is a list of Individuals, with Id, who have Christening facts, displaying source notes (from where and I need to get text still), where I can tell, if I captured the info in notes somewhere, if the Christening was in fact a Baptism and allow the Change Any Fact plugin to effect the change.

It's not perfect, since my notes aren't perfect, but I already see some changes and otherwise places to go re look and gather additional data.

If someone could tell me the "Text from Source" expression I'll be good!

Thanks.

Try %INDI.CHR.SOUR[1].DATA.TEXT%

But you said there might be several Sources, so you also need:
%INDI.CHR.SOUR[2].DATA.TEXT%
%INDI.CHR.SOUR[3].DATA.TEXT%
and
%INDI.CHR.SOUR[2].PAGE%
%INDI.CHR.SOUR[3].PAGE%

I do have multiple sources for these Christenings. But I don't want to keep adding columns to account for additional sources.

I don't think I can repeat an Individual to provide the data for multiple sources. (I.e if there's 3 sources, the individual appears on 3 lines, a non-issue if I sort on individual.)

So now I'm thinking I need to list, not by individual, but by source citations; filter on only source citations for Christening Events; and provide in a column the individuals name and RecordId linked to the source citation. (Multiple sources for a single christening event will just output multiple lines, which is what I'd want.)

(But now I'm spinning gears trying to figure this out. Is there a sample query that does something similar? Kind of like a "where used" look up?)

No, you cannot do that with a Query.
They are keyed to one Fact, or Individual, or Family, or Note, or other record type per row.
So when there are multiple fields like Source Citations you need multiple columns.

Program features such as Where Used, and Plugins are more flexible and can put almost anything they like on each row in the Result Set.

With such an unspecified number of Source Citations with both Where Within Source and Text From Source fields of unlimited size, you see why I baulked at adding them to my Plugin.

Is there nothing more concrete in those fields that the Rows filter could latch onto?
Any particular form of words that distinguish Baptisms from Christenings.

As a longshot, do Dates or Places help distinguish them?

If all else fails, and all you want is a list of Individuals with Christenings and their Source Citation fileds, then I could write a tiny Plugin to create the Result Set.

Thanks.

I'll just try with adding the extra columns. I'm going to catch a lot that way. (I typically open FH in 1/2 of my screen (I like to split my screen between two views, but if I drag FH to full width just work on this one topic, that will let me open up a lot more columns to view.) (I can also weed out a lot of extraneous source citations, like the websites where I found the info before I also found it in a more original source.) I'm only dealing with 430 Christenings after all. It'll just require some perseverance.

I am getting an error.

Warning: %INDI.BAPM._PRIM% Y ~ Invalid Tag.

Check that the Source and Target are compatible.

Is the Christening fact malformed? (I.e. rendered non-standard after multiple conversions to proprietary software and back out to gedcom?)

It is the BAPM Baptism event that has an unrecognised _PRIM tag with value Y.

Yes, this will have been imported from another product that I suspect identifies Primary/Preferred facts, but means nothing to FH.

You need to use the how_to:handling_unrecognised_data_fields|> Handling Uncategorised Data Fields advice to tidy up such UDF before proceeding.

Change Any Fact Tag 2.7 found three UDF tags:

_COLOR
_FSFTID
_UID

Under Individual Records. (None seemed Baptism related, per se, but I understand this kind of data in an Event where not expected would cause an issue.)

Without knowing the implication, I opted to not Delete every _x UDF Tag however.

None came up under Family Records, Source Tag Set, either.

That left the other plugin to see what I had, the UDF List.

That ran for about an hour, slowly churning through individuals, families, then sources, before crashing the program.

Change Any Fact Tag only lists Fact/Level 1 <UDF Tags> and not subsidiary tags such as the INDI.BAPM._PRIM tag you mentioned.

I advise that eventually the safest approach is use Tools > Fact Types to create three Custom Attributes named say COLOR, FSFTID, and UID. Then Change Any Fact Tag can change those hidden UDF into visible Attributes. It will even preserve any subsidiary UDF as Source Notes. However, I suspect that the _UID are simply redundant external product record id that can almost certainly be deleted, or if they have no subsidiary tags use Change Any Fact Tag to change into Automated Record Id, Custom Id, or Permanent Record No. But before doing anything read on...

Regarding the UDF List Plugin, it sounds like you have a very large GEDCOM database with plenty of UDF that have eventually confused the Plugin. The alternative is to use Tools > Find Uncategorised Data that only lists the records that contain UDF that you must hunt for. To do that open the Property Box of a listed record and select its All tab. Double-left-click on the record name top left to collapse the list, then double-left-click again to fully expand the list. All the UDF are marked with star-burst bullets. Then you can assess the extent of the problems. Only then can appropriate corrective action be considered.

BTW: Did the UDF List Plugin actually crash FH or did it just say Not Responding or leave the busy blue circular icon spinning? If it did not actually crash, then just be patient and wait. If there are a great many UDF, then the Result Set will be very large, and that takes a loooooong time for FH to compose. Once you have got it, either do not Close FH until most are sorted, or at least Save As a CSV file.

Thank you. I will try just that. (This database has been in and out of several programs. Started in TMGW, moved to FH5, Legacy, RootsMagic, and now FH6. It will have picked up some rough edges. FSFTID is Family Search Family Tree Id, so something, I believe, added by RootsMagic maybe as it synched my folks with FamilySearch? The COLOR tag too, as part of it's coloring option?)

It is a rather large database. (30K+ individuals.) UDF List did take about an hour to run. It ran through three progress bars, and on the conclusion the X in the upper right of the windows was an unusual red color. (I'm using Windows 10.) I did see Not Responding on the window title. Since it was past midnight at that point, it could be my Cancelling it, rather than waiting further, that caused the crash.

I will do as you suggested and see what I've got. Thanks!

The All Empty Facts query resulted in finding 17K empty Death facts. It would appear some software in the past added a blank Death record for every record where I didn't have one. There were also many empty Marriage facts, but those establish the link, so fine there.

I deleted all the top level UDFs, i.e. COLOR, FSFTID, and UID, with the Plugin.

I was going to run the UDF List Plugin but it started to bog down again.

I then used Tools > Find Uncategorised Data, got the Named List of records. That list has 38,881 items. (For a database of 35,064 Individuals and 17,945 Families.)

Browsing through the UDFs I see:

In a Christening (where I encountered the problem)
Under Source
Where Within Source = "Pg. 10"
* _TMPLT
--* FIELD
----* NAME = "Page"
----* VALUE = "Pg. 10"

Under another Record, another source where
Where Within Source = "Pg. 691, Raynsford, 9."
* _TMPLT
--* FIELD
----* NAME = "Page"
----* VALUE = "Pg. 691, Raynsford, 9."

In my newest individual entered. A Baptism. (And I didn't create a custom Baptism Fact. The Baptism Event is in the Standard Fact Set.)

Where Within Source = "Vol 55, Jan 1901, pg. 28"
* _TMPLT
--* FIELD
----* NAME = "Page"
----* VALUE = "Vol 55, Jan 1901, pg. 23"

(And the odd part here... I remember that entry error. When I created the source I originally entered it as Pg. 23. But I corrected it to Pg. 28. Why/how is the UDF Value remembering my original incorrect fact, which is otherwise correct in the Where within Source spot?

There appear to be a lot, A LOT, of these _TMPLT UDFs under every single source. These appear from the sources from my oldest entries to my newest.

The other UDF that appears in most, but not all, is _PRIM = "Y".

UDF List finally finished: Records in Result Set: 330,782. (A 49MB CSV file.)

I think the _TMPLT refers to a Source Template. Both RootsMagic and Legacy make use of Source Templates.

David

Often when exporting from other products such as RootsMagic there are options to exclude product specific tags, or to choose GEDCOM generic format. Those options should exclude such non-standard tags from exported GEDCOM.

It is obviously too late now to do that, but when imported to FH it would have reported all those UDF and I guess you ignored that.

The _TMPLT tag UDF can all be deleted, as they only repeat Where With Source, and that will also remove the subsidiary tags FIELD, NAME, etc.

FH does not touch those tag values, so any change you make to Where With Source will only be made there. Presumably if the change had been made in the other product it would have flowed down into the TMPLT.

_PRIM tag UDF can be deleted.

BTW: You can safely delete blank Marriage Events, because they do NOT make the link between partners. The Family record does that linking, and therefore supports unmarried couples.

Once I did a test import of my gedcom and saw all the new features in FH6, and, more importantly, all the media came through, and linked, (and properly filed in the various media subfolders I had), I didn't pursue further nuances of the import. (So, yes, I probably ignored those warnings, because it otherwise all looked so right.)

"The _TMPLT tag UDF can all be deleted, as they only repeat Where With Source, and that will also remove the subsidiary tags FIELD, NAME, etc."

I'm picturing removing these via the Results set. I can gather them all up by sorting on a column, if memory serves. (I'm not at my genealogy PC at the moment.)

The _PRIM flag as well. (It was TMGW that allowed "primary" facts to be designated. I guess this is how they did it.)

"FH does not touch those tag values, so any change you make to Where With Source will only be made there."

That part is curious. How was it possible for a brand new entry, for a brand new Individual, when I cited a source for his Baptism, this _TMPLT UDF was created. The Individual was not an import. I added him in FH. That _TMPLT UDF had to have been created when the source was cited again. (It was not updated, afterwards, when I circled around and made a correction to the Where Within Source.)

Does something in the Source Record drive the creation of these UDFs perhaps? (I.e. Sources imported over will carry on non-compliant traditions?)

I'm using the Standard Baptism Fact. What happened that my adding a source to it generated a _TMPLT?

P.S. Thanks for all the help. (My database is going to be better for it!)

Yes, you are correct about sorting on a Result Set column, then select UDF tags and hit Delete key.

I am mystified by the Baptism citation creating _TMPLT UDF tags.

Where exactly are those _TMPLT UDF tags:
Are they in the Source Citation displayed in blue?
Or are they in the actual Source record displayed in red?

How exactly did you add the Citation:
Did you Copy & Paste another Citation?
Did you link to an existing Source record?
Did you create a brand new Source record?

Mike, I'll run a test tonight (Chesapeake time) and let you know.

(I'll create a new individual, cite a more recent source, and screenshot the All screen (where the UDFs typically appear). I'll look at a/the source record as well. I've seen red text, and blue, in my sources in various views of them.)

Again, I appreciate your help and responsiveness.

It's the pre-import Source Records that are creating the UDFs.

A new source won't create them. No UDFs, the text is all blue.

Red Text is source, and Blue Text is individual, in the All screen?

Yes, each record type is colour coded in every All tab, and in the Records Window.

And done.

I've got a manageable list of 231 UDFs, all in either a custom address field, or a repository note. Something I can fix by hand over time.

Otherwise with your suggestings, 330K UDFs removed and my Christenings now properly Baptisms via this plugin.

Thanks!