Genealogy from the perspective of a member of The Church of Jesus Christ of Latter-day Saints (Mormon, LDS)

Sunday, May 3, 2015

The Mystery of the FamilySearch Family Tree Alternative Names

Quoting from a recent comment to my recent blog posts about cleaning up the Family Tree, 
Problem #1: After a temple ordinance is completed, "FamilySearch" adds REDUNDANT information (an alternate name that matches the record name). If they need to add this information, the least they could do is call it something other than "Birth Name". Perhaps, "Name when ordinances were completed" is more accurate. (The folks at FS have remarked that this feature helps when doing searches and finding duplicates, in case the record name gets changed. I tend to think there could be a better option.) 
Problem #2: When I noticed the redundant alternate name, I deleted it in several records (findarecord.com makes it very easy to see which records have "identical names"). In some of the records, however, something VERY STRANGE happened after I deleted the redundant name. From what I can tell, the alternate name appearing right above the alternate name I just deleted BECAME THE RECORD NAME and also disappeared! And in the history it shows I changed the record name. Which I certainly did not! I only deleted the redundant alternate name.
After checking the FamilySearch.org Family Tree, I do find that an "Alternative Name" has been added by FamilySearch on or about the same day the ordinances were performed.  This added name seems to be identical to the name that was submitted. A further comment indicates that this is a convenient way to be notified that the ordinance work has been done. Subsequently, blogger Amy Archibald of the Revealing Roots and Branches blog, sent me several examples from the Family Tree.

This is not the problem I have outlined in my posts about cleaning up the Family Tree. Those entries come in with a reference to a "Birth Name" not an "Alternative Name." The Alternative Name issue is more serious because if the name is different than the one listed in the Details section of the entry, there is a need to verify and document the Alternative Name. If, as observed, FamilySearch is using the designation of an Alternative Name for some other purpose this could create some difficulties.

I do not have a solution to this problem.

9 comments:

  1. Both of the problems related here have been present ever since Family Tree opened and have been reported repeatedly and discussed at length on the feedback boards.

    Regarding #1: This addition of an alternate name by FamilySearch is a consequence of Family Tree’s continued dependence on New Family Search. I’m pretty sure it was Ron Tanner that originally explained the course of events. Basically, whenever an ordinance is completed, the information as added as a new record combined into the existing record of the individual in NFS. This triggers a synchronization with Family Tree which adds the new alternate name.

    The real source of the problem is that the programming routines that control temple actions in Family Tree all reside in New Family Search, which is why New Family Search cannot be completely turned off yet. Those are some of the routines that are currently being rewritten and why so many requests for Family Tree features on the feedback boards are met with the response, “Not until we get off of New Family Search.”

    This addition of alternate names whenever an ordinance is done will stop as soon as NFS is completely turned off. The advice we keep getting on the feedback boards whenever someone official responds is to be patient and keep deleting the redundant alternate names added by Family Search.

    Regarding #2: There does not seem to be an official explanation of this, but I have my own theory derived from seeing this happen many times when Family Tree first opened. I only run across it rarely now.

    I am suspicious that it is an artifact and flaw introduced when data was originally transferred from New Family Search that can only be fixed one name at a time. My theory is that when the data was transferred, the main name in the Vital Information section, being copied from the list of the names in NFS was also copied into the Alternate Name section and the two values remained linked. Or in other words, the data pointer for the main name and the alternate name ended up pointing at the same database cell instead of two different database cells as should have happened. So when the alternate name is deleted, that single cell gets deleted and both appearances of the name get deleted.

    My theory is based on that fact that the problem seems to only occur under the following conditions:

    1) The vital information name has never been edited and saved since its original import from NFS.

    2) There is an alternate name which is identical to the vital information name which has also never been edited.

    If that is the case and the alternate name is deleted, the vital information name is also deleted and and different alternate name is put into the vital information area. Whoever deleted the alternate name appears in the change log as having changed the vital information name.

    This only happens once. I've never seen a repeat occurrence on the same person. Also, if the vital information name has been edited, it does not happen. It appears that any editing of the names fixes the database pointers and generates unique database cells for each of the two names.

    (I would be happy to be told my theory is completely wrong and be told what is really going on!)

    ReplyDelete
    Replies
    1. Thanks for the rather detailed explanation. I assumed it was something like what you explain.

      Delete
  2. First of all, wow.

    Thank you, James. Your blog seems to be just as effective at eliciting meaningful responses as FamilySearch Help Center/Missionaries itself (maybe even more effective)! Thank you for taking me seriously. Wow, it feels good to be heard!

    Gordon, thank you for responding to this issue so thoroughly. Regarding your theory for problem #2, here is a case where I created the person last July, so from my understanding, she was never in NFS (right?).

    Addye L Heck (LXQS-5LJ)
    * Ordinances and redundant alternate name added 14 March 2015.
    * I deleted redundant alternate name and record name automatically changed to Addye L Barr 25 April 2015. History shows I changed the name, which we all understand by now that I did not. What the history does not show is that Addye L Barr was also deleted as an alternate name, but that's what happened.

    The rest of the recent activity in the history of changes shows that I tried to put everything back in it's proper place. Except for.... Interesting, I just noticed FamilySearch added back the alternate name on 29 April 2015, when another ordinance was completed, but it still attributes myself (spoe) as the last to modify the name (as it appears in the list under Other Information).

    Anyway....

    ReplyDelete
    Replies
    1. Heh, heh... I forgot to finish my statement!

      Anyway.... THANK YOU, both. And thank you Amy Archibald for providing examples and also helping me through all this!

      Delete
    2. Thanks for the kind comments and additional information.

      Delete
  3. I have had a lot of duplicate names to delete and record names to change (usually adding the middle name) but what I found is that if I changed the record name and deleted an alternate name at the same time, it messed up the record name. My solution has been to just do one at a pass, and return later to do the other.

    ReplyDelete
    Replies
    1. Thanks, that sounds like a work around.

      Delete
  4. Gordon might be able to clarify this, but I remember Ron Tanner saying all that Gordon said above, but also said that Church Membership Records from that department get involved in the temple assignation to a person, and that muddies the Temple>new.familysearch>Membership>Family Tree pathway. It is a miracle that things work as well as they do!

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete