Jump to content


Photo

FamilySearch Auto Match Not Working


  • Please log in to reply
13 replies to this topic

#1 tmduffy52

tmduffy52

    Advanced Member

  • Members
  • PipPipPip
  • 115 posts

Posted 15 August 2019 - 09:10 AM

I just imported, using a GEDCOM file, my data from Legacy Family Tree. Each 2,450 ancestors were linked to FamilySearch in Legacy and they each had a valid FS ID#. After the import, I opened up the RM7 FamilySearch Central feature and there were no matches. I ran the AutoMatch tool and only got 1,868 matches out of the 2,450. I reviewed my imported RM data. Persons that are showing up in the Not Matched list do have FS ID#s listed as a Fact. So it actually appears the FS ID# data did import but for some reason, RM did not locate these individuals when attempting to link them to FS. I just tried matching an unmatched ancestor using the FS ID# and it matched up just fine. Why didn't RM find the match in FS?

Ted



#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 15 August 2019 - 11:06 AM

RM shouldn't be doing that. I suspect Legacy exported in the GEDCOM the FamilySearch ID's as facts. 

 

AutoMatch will only match if it's a close match. If there are no relationships it won't match. 


Renee
RootsMagic

#3 tmduffy52

tmduffy52

    Advanced Member

  • Members
  • PipPipPip
  • 115 posts

Posted 15 August 2019 - 03:58 PM

Thanks Renee,

Yes, all of the FS ID#s are showing up as Facts in RM. Is this not the way it is done? If I have accurate FS ID#s, why wouldn't RM match them all? What do you mean by "close relationships"? Wouldn't RM use the FS ID# in it's matching process and all of my names have FS ID#s.



#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 15 August 2019 - 04:30 PM

Thanks Renee,

Yes, all of the FS ID#s are showing up as Facts in RM. Is this not the way it is done?

 

FS ID numbers are definitely not facts in RM in the same sense that birth, marriage, and death are facts in RM. For example, you cannot see the FS ID on the Edit Person screen. You cannot make the FS ID into a column in People View. You cannot make the FS ID into a column in Custom Reports. You cannot search for the FS ID. You cannot use FS ID's as criteria for making a group. I'm pretty sure that the only way to see FS ID's in the RM database is to click the FS icon for the person. If you have the computer skills to run SQLite queries, you cannot see the FS ID's in RM's EventTable. You have to look in RM's LinkTable instead. The FS ID simply isn't a fact.

 

I can't address how and why RM imports Legacy Family Tree data the way it does. Perhaps RM should recognize Legacy Family Tree's FS ID fact and store the data in RM's LinkTable where all the other FS ID's are stored. But the import apparently doesn't work that way.

 

Jerry



#5 tmduffy52

tmduffy52

    Advanced Member

  • Members
  • PipPipPip
  • 115 posts

Posted 15 August 2019 - 04:43 PM

Jerry,

My RM Pedigree View shows FamilySearch ID#s next to the name instead of RIN#s. They also do show up as a listed Fact in the person's Edit screen. The Fact is "FamilySearch ID#" and the # shows up in the Description field.



#6 tmduffy52

tmduffy52

    Advanced Member

  • Members
  • PipPipPip
  • 115 posts

Posted 15 August 2019 - 05:02 PM

Renee, are you saying in your post above that the auto-matching process only uses ancestor data such as name, birth date, etc. and not the FS ID#? If so, this answers my question about not having a 100% match of my 2,400 names.



#7 Bob C

Bob C

    Advanced Member

  • Members
  • PipPipPip
  • 235 posts

Posted 15 August 2019 - 05:54 PM

the auto-matching process only uses ancestor data such as name, birth date, etc. and not the FS ID#

 

Correct!

 

Also, if you check Tools>File Options and the number to display after the name you will find you have selected FSID. If you change it to RIN, that will be the number after all your names. It also sounds like you forced your Legacy GEDCOM file to have FSID as a fact and imported that into RM which RM did as a custom fact.



#8 tmduffy52

tmduffy52

    Advanced Member

  • Members
  • PipPipPip
  • 115 posts

Posted 15 August 2019 - 07:22 PM

Bob,

Is your "Correct!" above related to my response to Renee about auto-matching not using FS ID#s?



#9 Bob C

Bob C

    Advanced Member

  • Members
  • PipPipPip
  • 235 posts

Posted 15 August 2019 - 07:54 PM

Yes, I copied your question in italics to show your understanding of her reply was correct.



#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 15 August 2019 - 07:55 PM

I obviously need to make one correction. The Family Search ID can be displayed in lieu of the RIN, anywhere the RIN is displayed. So it can be given considerable visibility in a certain sense. But I believe all the other limitations I mentioned are correct.

 

Jerry



#11 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3449 posts

Posted 15 August 2019 - 08:05 PM

The key takeaways, to understand, seem to be:

1. RootsMagic is not programmed to utilize a FACT with FS ID's as a value to ~DO~ the search for AutoMatches

2. RootsMagic stores FS ID's (into a different part of the database than FACTS) apparently DURING -or- AFTER the AutoMatching process.


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 16 August 2019 - 07:04 AM

2. RootsMagic stores FS ID's (into a different part of the database than FACTS) apparently DURING -or- AFTER the AutoMatching process.

 

RootsMagic stores the FamilySearch ID's into a different part of the database than facts AFTER the matching process. The matching process can be manual or automatic, and the storage of the FamilySearch ID's is the same either way. I think that after the matching you can't tell if the match was achieved manually or automatically.

 

From a relational database perspective, the linkage between the FamilySearch ID's and the RootsMagic RIN's is achieved by a JOIN between the PersonTable and the LinkTable. The LinkTable stores the FamilySearch ID's, and it includes the RootsMagic RIN for each FamilySearch ID. The RIN numbers are used for the JOIN. It's a similar concept to the way RM stores names. Names (including Alternate Names) are stored in their own separate table, and the linkage between names and people is achieved with a JOIN. The difference is that names are presented in the Edit Person screen as if they were facts, even though they are stored in the NameTable instead of being stored in the EventTable where facts such as birth, marriage, and death are stored.

 

I suppose it would be possible and fairly easy for RM to show FamilySearch ID's as facts in the Edit Person screen, but you wouldn't want them to be able to be edited from there. They should only be able to be "edited" by going through RM's standard Family Search interface. And I suppose that it would be possible and fairly easy for RM to make Family Search ID's available to RM's searching and marking dialog. Names are certainly available to RM's searching and marking dialog, even though they are not stored in the EventTable. Searches such as FSID>Exists>Is True, FSID>Exists>Is False, FSID>Contains, etc. would be very useful. It's the sort of thing that's extremely easy to do in SQLite if you are able to use SQLite, and which is not really possible in the RM user interface.  Well, you can get a list of FSID>Exists>Is True simply by going to RM's FamilySearch interface. You will see a list of matches. But you can't do things like FSID>Exists>Is True AND Birth>Date>Is Before>1900 or anything like that.

 

Jerry



#13 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 16 August 2019 - 10:12 AM

The FamilySearch ID's are embedded into RM but are not true facts. This makes them editable when the FamilySearch ID changes on FamilySearch. For example: when two individuals are merged if the embedded FSID was lost the next time you view the person in the FamilySearch Person Tools the FSID will be updated. If the person was deleted instead of merged that wouldn't happen. If this was a fact inside RM the updating would not be possible.

 

Even though the FamilySearch ID is not a fact in RM it can be displayed after a person's name. It can be added as a column in the People View. You can create a custom report with the FamilySearch ID. You can also filter on groups and search on the FamilySearch ID. 

 

The reason your Legacy FamilySearch IDs came into RM as facts is because you selected the export option "Export all other ID numbers as Events".  This caused the embedded FSIDs in Legacy to come in as facts. If that option wasn't selected you should have seen the individuals still matched to FamilySearch. Once it's a fact there is no way for RM to use that during AutoMatch. 

AutoMatch will look at the person's vital facts and relationships they are connected to to determine if they are a close match or not. It will not look at the fact called FamilySearch ID's and assume those number are something to match against. 


Renee
RootsMagic

#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 16 August 2019 - 12:36 PM

Well, crow tastes pretty good sometimes. I was wrong about FS ID not being a column in People View and not being a column in Custom Reports and not being searchable. It is all those things. I thought I checked them pretty thoroughly, but apparently I didn't check carefully enough. My apologies.

 

Jerry