19 replies to this topic

[GlenB]

I have matched some people in my database with FS/FT and made new connections. Then I import the information on the new people, and I go to the sources tab and import some of the sources as well. It works, but ...

 

In reviewing the new information I have there are some duplicate fact types. In my list of facts now there are 2 fact types named Confirmation, 2 named Census, 2 named Immigration, and 2 named Probate.

 

The original ones all have a sentence defined for use in narrative reports, while the new fact types do NOT have such a sentence defined. That's the only way I can tell them apart when I look through the list of fact types. The name is exactly the same (so I guess that database field allows duplicates, which is a bit surprising).

 

I believe the fact type name field should be unique. In the general case, if a duplicate tries to be created, it should get a (1) or something on the end to establish that it is different, or the duplication should be prevented outright. In the specific case of an import from FS/FT where you know precisely the data and structure of both systems, the import should seemlessly prevent the duplicate and render the imported fact using the existing RM7 fact type list.

[Renee Zamora]

It should have used the RM default fact on each of those. It really depends on how someone designed the custom fact on FamilySearch. If you give me the FamilySearch ID of someone that brings in an extra fact type I can see what's happening. 

[GlenB]

Sorry Renee, I have cleaned them all up already. However, there were only a few Probates, and I think I can identify which Probate facts were imported from FS because of the way they write their source info. However, I cannot now know which one(s) of them created a new Probate fact type and which one(s) mapped correctly to the existing fact type.

 

These are the FS IDs to review: LTDK-FFC, LJJN-13C, MJ68-GS7, KH97-NKX, K8G2-FFB, LX3J-6S8, MXPK-N82, L29P-5SS, KLYG-JCB.

 

I should note that there was only ONE duplicate fact type in each of the 4 types I mentioned, meaning that, if the FS fact was strangely constructed there was only ONE way in which they were strange and all the strange ones then all mapped to that one new strange fact format. So in your review of the Probate fact on the IDs above they should fall into only 2 groups - ones that map correctly to the standard RM fact type, and ones that all map to the same "strange" additional fact type.

 

Any reason why the Fact Type table does not have the Name as a unique key? I know, it's only used for presentation and internally you'll be using a code number which certainly is unique. But ... just curious I guess.

[Renee Zamora]

I had no problem adding the Probate fact from FSFT to RM which each of those FSIDs. There was no duplicate fact type added.

 

I noticed that they were from Denmark. By any chance are you using a language setting on FamilySearch to view these individuals? Just makes me wonder if there are some special characters that making it look like a different fact type, than I can't see with my FamilySearch settings. 

[GlenB]

Thanks for looking in to this.

 

I'm unaware of ever setting the language on FS, not even sure where to do that. And I have used FS for far more than some Danish people. If you can tell me where to find such language settings I can let you know how I have mine set.

 

It is interesting to note that the RM Probate fact name and the newly created one appeared (to me anyway) to be spelled exactly the same, no trailing space or non-character so far as I could see in RM. Would a new fact get created if the name was different, or if any of the fields for the fact were different, or ... what COULD cause the duplicate? There much be some matching logic: there is a fact to be entered for a person ... does it match an existing fact type (what fields are checked to determine that?) ... if Yes, use the existing fact type else create a new record in that table. Hmmmm....

 

I guess I'll have to watch for this again and send you details when I hit a newly created duplicate fact type.

[Renee Zamora]

I guess I should have said is FamilySearch set to anything but English? It's not translated into another language. That is what my setting is.

 

I would need to recreate the issue to see what is happening. So if you get it to happen again with the steps and person it happens with, then let me know. There are no other reports of this happening. All I can think of is you added those facts by some other means than FamilySearch into RM.

[GlenB]

Go to FamilySearch.org and login using the same account (only account) that I gave to RM.

Settings - Account has no language information

Settings - Notifications - Preferred Language = English

Settings - Preferences has no language information

So I guess I'm not sure how one "sets" FamilySearch to anything but English - where is that?

FS is so US-centric that they may not even be aware there are other languages or code sets <grin>.

 

I most certainly have not used ANY means to add facts to ANY person in my database except typing it in manually (with some copy/paste) or the RM FamilySearch Central automated fact transfer from FS to RM.

[Renee Zamora]

I believe you do it under the preferred language setting. Though obviously your using English, and that wouldn't exclude what I was trying to look at for your issue. Since I can't recreate this second fact, when adding a person or fact into RM from the FSID listed, all I can think of is that they came in through other means and not a FamilySearch import. 

[GlenB]

OK, I think I have all the pieces of this for you to track. I am using the FamilySearch Central. It told me there was new information for a bunch of people, click on the underlined count of people and get a dialog with names down the left border and the 2 comparison panels in the main area. The FS person has a Confirmation fact that I do not have so I click on the box and add it to the RM person. See Capture1 - note that it did not add the Confirmation in the expected place on the RM person but created a new "line" on the display that also was called Confirmation. Capture2 shows how the guy looks when I go back to RM, seems quite normal. Capture3 shows the definition of Fact Type for the original RM created Confirmation. Capture4 shows the Fact Type created for the new FS import created Confirmation.

 

Capture1.JPG-----------------------------------------------------------------------------------------------------------------

 

Capture2.JPG-----------------------------------------------------------------------------------------------------------------

 

Capture3.JPG-----------------------------------------------------------------------------------------------------------------

 

Capture4.JPG-----------------------------------------------------------------------------------------------------------------

[kbens0n]

OK, I think I have all the pieces of this for you to track. I am using the FamilySearch Central. It told me there was new information for a bunch of people, click on the underlined count of people and get a dialog with names down the left border and the 2 comparison panels in the main area.

Ah, but the new information is *only* DEATH and ALT. NAME

The FS person has a Confirmation fact that I do not have so I click on the box and add it to the RM person. See Capture1 - note that it did not add the Confirmation in the expected place on the RM person but created a new "line" on the display that also was called Confirmation.

Actually, Capture1 shows (in BOLD) *identical* Confirmation facts and hints (in Italics) what type of fact they would be if transferred between panels (same for all fact differences)

Capture2 shows how the guy looks when I go back to RM, seems quite normal.

Well actually, you should have expected two Confirmation facts in the left panel (it already had one and you transferred another) BUT RootsMagic apparently merged (or threw away) the EXACT duplicate you've tried to transfer to the left (likely because they are identical).

Capture3 shows the definition of Fact Type for the original RM created Confirmation. Capture4 shows the Fact Type created for the new FS import created Confirmation.

Here, RootsMagic has created a separate second user-defined fact (note the NEED TO DEFINE SENTENCE] with a matching fact name... and yet didn't do the same back in Capture2. Looks like a flawed merge process (to me).

[GlenB]

No, not sure that my explanation and your understanding quite matched up.

 

Re your comments on Capture1

Capture1 is AFTER I clicked on the Confirmation fact in FS and transferred it to the RM person. I didn't know it was going to "mess up" until after I had done that and seen what was presented in the UI.There was no Confirmation fact in RM before. Yes, the DEATH and ALT.NAME are different, but I did nothing to try to make them the same and they're not the issue.

 

The transfer of the FS Confirmation fact did NOT put the new fact in the existing RM Confirmation fact, that is why it is still in Italics. Instead, it created a new Confirmation fact (and Fact Type) and with that created a new line on the RM person display which it placed below the Residence lines.

 

Because it sees the Residence lines as being the same in RM and in FS it has coloured them both green AND aligned them with each other. But the Confirmation facts are not seen as being the same therefore not green and not aligned with each other. Had the Fact Type been the same and the data different then they would have been aligned but coloured in either yellow or white. But because they're not aligned it means that they are seen as different Fact Types - which is the problem.

 

The two Confirmation facts contain identical data, yes, because I transferred it from FS to RM. This screen capture is not presenting what it WOULD do, but presenting what it HAS done. The data being identical (and therefore green) is not recognized because the Fact Type is different.

 

Re your comment on Capture2

No, I did not already have a Confirmation fact on that person. There is only one Confirmation fact for this person now and it was **just** transferred in there from FS. Capture5 shows that the only Confirmation fact on this person is the one that has the undefined sentence type which is the new Fact Type created by the import step.

 

Capture5.jpg-----------------------------------------------------------------------------------------

 

Re your comment on Capture3/4

I hope you see now that the second Confirmation fact is new and is incomplete. It was not there before. It is used only by the person to whom I just transferred the fact from FS to RM. There was no merging of the new FS fact's data into the existing RM fact's structure. For some reason, the FS fact is not recognized as being the same Fact Type as the RM fact. It has nothing to do with the data from FS that is presented in the UI about the fact contents, and everything to do with the data from FS that is used to decide if a Fact Type coming in matches one that already exists ... or not.

 

If you were to accept my hypothesis as being possible, what test could I do that would prove to you that it is or is not happening?

 

Here's one more that I ran in to if you want another to investigate: MCJV-88Z

[kbens0n]

No, not sure that my explanation and your understanding quite matched up.

You're right. I misinterpreted the Capture1 to be prior to transferring any facts. I'm afraid my post is just a distraction. SORRY

[GlenB]

And here's another instance. Capture6 is before, and capture7 is after I clicked on the square beside the FS Confirmation fact and told the dialog to add the fact to the RM person. I had several that worked correctly recently, but not this one. Ooopppps, sorry, I should have saved the FS IDs for the ones that worked so you could compare them. I'll reply later with any more that I run into which work as expected.

 

Capture6.JPG ------------------------------------------------------------

 

Capture7.JPG ------------------------------------------------------------

[Renee Zamora]

I tested it and it made the 2nd confirmation fact in RM. Then I went on FamilySearch to look at this custom fact that someone entered. (Click Edit on the confirmation fact.) They didn't fill out the description area, it only had a title. So it wasn't complete. Once I added confirmation in the description field for the fact it used the confirmation fact in RM when being added. 

[GlenB]

Good debugging, Renee. I kind of figured the problem would be on the FS end <grin>. So, now, how to handle that? It seems unreasonable to ask the RM user to check every single Confirmation fact before importing it. The field that is not filled in is not presented in the comparison UI, so it takes clicking the Edit every time. Maybe you could check that field for us and put an alert icon beside the fact if it is incomplete so we can edit and correct before importing? Recall from my original post that it wasn't just the Confirmation fact type for which I experienced this issue - it also happened with Census, Immigration and Probate. 

 

Presumably, for each fact type, there are a few fields which you use to "match" the FS fact to an RM fact. If you looked at those in advance of a request to import the fact and presented an ALERT icon whenever the FS fact was going to cause a "new" RM fact to be created, then we could take manual action as required, or let it go ahead, as we choose.

 

If you have tech contacts in FS perhaps you could get them to clean up their database and put in code to prevent a recurrence ... but I'm not holding my breath on that one!

 

If you need more examples:

People that worked as expected and did NOT create a fact using the new incomplete fact type for Confirmation: K8JC-P6K

People that used the (now existing in my database) "incomplete" Confirmation fact type: KD3P-8J8, LYJW-BZP

[Renee Zamora]

I'll put it on the enhancement request list.

 

Not really sure what FamilySearch can do for users that add custom facts without all the details in it. You might want to look at the submitter name for the fact, by clicking on the blue i icon on the fact on the FS side. That might help you determine which people to watch out for.

 

What I would actually do is add the fact regardless then click on the "Edit RootsMagic person" button if the fact didn't line up. Highlight the fact and click on Options>Change fact type, and select the fact that has the confirmation with the sentence template showing. I think that faster than editing it on FamilySearch. Once you have all the confirmation facts changed you can delete that extract confirmation fact without the sentence template. You can print a list of anyone still using that fact to switch them now. 

[GlenB]

That works. I didn't know I could "change fact type". In previous instances I have been copying and pasting the fact date, place, source references and notes to a new fact of the correct type and that's PAINFUL when you have a hundred or more to do!

[GlenB]

I notice also that the last few Confirmation facts that I have imported from FS to RM, and which used the ill-defined Confirmation fact type, had some text in their "Description" field ... yet the RM supplied Confirmation fact type does not appear to have any "Description" field. Maybe if the RM type had such a description field then the import would work as desired and not create a new fact type. Any reason why there should be not description field in the RM fact type?

[GlenB]

So now when I import a Confirmation fact from FS to RM, and if that fact has some text in the Description field, it imports in the RM fact type BUT the Description text cannot be edited/deleted.

It's as though the recognition of the fact type requires "something" to be in the FS Description, but it better not be anything useful because the UI currently can't provide access to it.

I can "Change fact type" to use the ill-formed one,and then there is a Description field visible and I can cut the text from there and paste it into the Note field.

If I did not have this ill-formed Confirmation fact type lying around in my Fact Type table then how could I ever get to that Description text?

Afterwards I can "Change fact type" back to the RM version and all is well.

 

Capture9.JPG----------------------------------------------------------

As imported from FS to RM but using the RM fact type template (see lower right sentence). Note the text on the Confirmation line on the left saying "Confirmation in the Danish Lutheran Church"

 

Capture8.JPG-------------------------------------------------------

After I change fact type to use the ill-defined one (see lower right sentence). Now we can see/edit the text in the Description.

[Renee Zamora]

That's interesting because I thought the FT API didn't have a description field. That is why we cannot send them. I would imagine its not an option on their default fact types. If you find things like that in description field that you cannot edit you can go into the Lists>Fact Type List and Edit the fact to enable the description field. If you are writing a sentence template you need to add < [Desc]> to it. 

 

I just checked and the default facts on FamilySearch don't have this description or detail field. When you hover over the fact in Share Data or look at the more info icon, the description is called the Detail field. I can see Details field on the primary facts but no way to add anything to them on FamilySearch itself. On the custom event for Isaac's confirmation you do see the details on Share Data when hovering or under more details.