Merge error message - whaaaaa?

LegacyUser

Justin Masters said: I tried merging two people today and got a message I've never seen before, and don't understand WHY I'd get it.

It says: "These two people can be merged, but only if the possible duplicate is the surviving individual. Click Switch Positions to change the merge order.



Any idea WHY I'd get such a message?

LegacyUser

DougHo said: I believe a typical reason is because the person on the right was a member of the church and it has info relating to their church membership record. In such case they want the church membership record to be the main one in the system.
Non-members like myself can't see those details inside the record, so we can't consider them for attempted merge.

In a quick look at those two, it seems like the one on the left was created few years ago from a GEDCOM upload, while the one on the right has been in system long time with lots of history. So that is the one I would want to survive, if I was doing such merge.

LegacyUser

Cindy Hecker said: I've gotten the message before, can't tell you why but I switch the positions and move the most accurate information to the surviving individual.

LegacyUser

Cousin David said: The person requiring "remaining" has more information and Ordinances complete.

LegacyUser

Justin Masters said: Okay, thank you

LegacyUser

joe martel said: This is a software imposed requirement. By switching the survivor the database can accommodate the resulting survivor's set of database entity relationships (parent/spouse relationships, not-a-match, and temple ordinance references...). One design is to force the switch but would require adequate warnings to the user that the software is switching it for them.

LegacyUser

Justin Masters said: Joe, I'm afraid there's some context that I'm missing. The resulting survivor's set of database entity relationships?

I've swapped and merged them by now, but if memory serves me correctly, both persons had relationships, etc. established, so I'm at a loss to understand a lack of those on the part of either one, leading me to believe that there's some other context here.

LegacyUser

joe martel said: Sorry for the database talk. Basically all the stuff that go into connecting a Person to other database things like other Persons (relationships), changelog, temple, ... These Persons can still get big with all the connected pieces. 

LegacyUser

Justin Masters said: The database talk isn't what I'm hung up on. I'm left with trying to understand why a merge with one person on the left can't be done until the person on the right becomes the person on the left (switching positions).

To me, pointers to other relatives or merged attributes would be similar, regardless of who is on the left.

That's where I'm getting hung up on.

The "WHY?" of it all.

LegacyUser

Tom Huber said: Looks to be a refinement of the merge process, something that evidently was discovered, possibly from merges that took place in the recent past resulting in calls to support.

After the database in nFS was severed from the database in FS, the need to have a merge take place in a certain order appeared to have been resolved. This recent change suggests that another problem appeared, which could only be resolved by reversing the order of the merge.

I think that is what Joe was saying.

But I could be wrong.

LegacyUser

Brett said: Joe

What I do not like about the "... software imposed requirement ..." is that in certain cases the OLDER individual/person in "Family Tree" CANNOT be the "Surviving" individual/person.

I am sorry; but, whatever is involved in this "... software imposed requirement ...", that is NOT ACCEPTABLE - the User/Patron SHOULD ALWAYS be the one to choose who is the "Surviving" individual/person, NOT the "System".

This "... software imposed requirement ..." NEEDS to be REMOVED.

'Thank You' in advance.

Brett

ps: I have had a number of situations where an OLDER ( records both, (1) pre.2012 in "New.FamilySearch"; and, (2) later "Family Tree" ) well "Sourced" individual(s)/person(s) in "Family Tree" could not be the "Surviving" individual/person; and, had to be "Switched" with a VERY recently "Created" individual/person - NOT ACCEPTABLE.

LegacyUser

Adrian Bruce said: Now I'm getting completely bamboozled.

My mental map of what happened behind the scenes (in a merge) to all that LDS stuff that I don't want to know about, was that everything got merged and all the LDS "stuff" ended up on the merged person, nothing was left behind and I didn't need to worry about which I merged into which. (Generally I would keep the more detailed profile as the survivor but that's just a general principle)

But this message seems to imply that there is stuff that cannot be merged over from right-hand (to be deleted) to left-hand (survivor), despite all what I thought the previous assurances had said!

Is it specific stuff that can't be sent "right to left"? Is it about the amount of stuff? Or what? I've never seen this message, it has to be said - but if I had, I'm not sure that I'd have believed it given those previous reassurances, and would have suspected a bug.

LegacyUser

Tom Huber said: We really do need to know the "why" the merge must take place in one direction. Is there something in the original record that can't be (or isn't) moved? If it is, then knowing what that is can and should allow us, as users, to duplicate the information so that the marge can take place with either record being the surviving record.

LegacyUser

Tom Huber said: Brett, what you want and deem acceptable may be a problem. We really do need to know why... Back in the days when nFS and FS were still "joined at the hip," it was a matter of logistics between the two databases and so what you called unacceptable wasn't a matter of choice. It was a requirement of the way the systems communicated with each other.

The question is whether or not you would consider having the site shut down for not just several days, but it could take weeks or even months to resolve the logistical problem between the two databases.

To me that would be unacceptable, and to simply call the requirement (due to some internal logistical problem) unacceptable is no more than a willingness to accept what is.

We don't know what this new requirement comes up, but the engineers may be facing the same kind of dilemma as they did when the two systems were "joined at the hip."

LegacyUser

Brett said: All

The ONLY reason that I would accept a requirement for a "Switch", is the "Surviving" individual/person WAS, in fact, a Member of the Church; and, the "Surviving" individual/person (that required switching) was that that of the official individual/person from Church Membership Records.

For example, the official "Me" from Church Membership Records SHOULD be the "Surviving" individual/person; whereby, the other six (KNOWN) "Duplicates" of me are subordinate to the official "Me"; and, as such, they would become the "Deleted" or "Archived" individuals/persons.

Brett

LegacyUser

Brett said: Tom

So, lets be told and hear about what this "... software imposed requirement ..." is!

Brett

LegacyUser

Adrian Bruce said: I completely agree we need to understand what the real, underlying, root cause is. With respect to Joe's comments above, I'm glad he's actually seen this thread but I don't feel he's told us the root cause - and I'll bet he understands that very well himself!

I have absolutely no idea, Brett, whether your speculation has anything to do with the root cause here - if that were the case, though, I'd have thought that the error message could have been a lot more specific...

LegacyUser

Tom Huber said: I think I found out what is going on with this particular issue.

Today, I was capturing Illinois death certificates at the FHC when I ran into a situation where both husband and wife had duplicates. What was strange was that the duplicates had the husband as a female and the wife as a male (she was in the husband position).

So, after trying to merge the records (which it would not let me do), I gave up, finished the shift at the FHC and came home. Then I decided to split apart the incorrect sex duplicates, so I could correct the sex. Then I could merge the resulting duplicates with the records.

What happened is that the system wanted me to reverse the two (added: male duplicates) during the merge. I had previously intended to merge toward the correctly marked record and leave the corrected record as a merge-deleted record. The ordinances were all correct in the to be surviving record. (Added: Now that I've looked over the records, I believe that I was actually merging toward the record in which I had changed the sex.)

Since I had to switch the two records, the system now has the surviving record flagged with the "This person's ordinance status is not available. Please contact FamilySearch Support if you are a relative and need more information." message. I'm going to wait until next week before I send in a request to get the problem resolved.

By the way, the male used a girl's spelling all his life and it was even recorded that way on his death certificate. He spelled his name as Carol. It is spelled that way on the 1900 U.S. Census Enumeration. But in several places, it is spelled Carl.

What surprised me was that when I went to clean up his wife's record and get her sex correct in the duplicate, I could not find the incorrectly marked duplicate. Now I wish I had captured all the screens, so that engineering could take a look.

All of the records date back to 2012, so this is something that existed from nFS days.

(I found the wife by going to the merge deleted record for the husband and using its change log. When I corrected the sex for the woman and merged the two, there was no complaint from the system. In looking at the records, I must have set up the merge for the husband with the record that I corrected as the surviving record.) Now all of the wife's ordinances are marked with the same message as the husband.

I'm thinking it may be more than a sex issue, but one involving the fact that the to be surviving record had the sex changed and also was not married after I split the couple apart to fix the sex. And/Or the issue involved ordinance data.

We really need FS personnel to verify the why, but I suspect it has to do with incorrect sex and/or marriage status for the surviving record. Behind the scenes, it may also be how the ordinance data will be impacted.

LegacyUser

Brett said: Adrian

Likewise, I have absolutely no idea what this "... software imposed requirement ..." is!

But, to be honest, I do not care ...

The ONLY acceptable requirement for a "Switch", is the "Surviving" individual/person WAS, in fact, a Member of the Church; and, the "Surviving" individual/person (that required switching) was that that of the official individual/person from Church Membership Records.

"FamilySearch" NEEDS to address/fix this "... software imposed requirement ...", nothing more, nothing less.

Again, excluding the aforementioned, the User/Patron SHOULD ALWAYS be the one to choose who is the "Surviving" individual/person, NOT the "System"

Brett

LegacyUser

Justin Masters said: Actually, Adrian, I can see a reason why you WOULDN'T want the error message to be more specific.

And that would have to do with not wanting a non-member to be coming along (closely affiliated with another religion, possibly hostile to the church) and seeing a message that says in essence, "Your ancestor was a member of the Church of Jesus Christ of Latter-day Saints" and you CANNOT merge his record any way but towards the church record.

But my speculation there...

LegacyUser

Justin Masters said: Tom, your wish is my command...

(waving my magic wand...)

try beta.familysearch.org

(you're welcome!) :-)

I forget about it at times, but this gives you a "backwards looking window" at times that are VERY convenient to use for troubleshooting.

LegacyUser

Adrian Bruce said: That sort of thing did occur to me, Justin, but it would be an odd genealogist who was (a) possessed of a virulent antipathy to the LDS Church but (b) was working in FamilySearch. Speculation again...

LegacyUser

Tom Huber said: Thanks, I think I'm going to hold for now, but for those interested, the PIDs for the couple are L6VV-WTW and L7N3-RVX if anyone wants to go over there are take a look at them in their pre-today state.

LegacyUser

Justin Masters said: Well, I direct the origins to my thoughts to the uproar that Jewish individuals had with holocaust victims/survivors.

As we spread into other regions of the world, some with distinctly aggressive feelings towards ANY Christians... even at the peril of death, I think this could be one possibility.

LegacyUser

Brett said: Adrian & Justin

We do not have to be "told" that the individual/person that needs to "Survive" was a Member (of Record) of the Church, all we need to know (be "told') is that that individual/person [who was a Member (of Record) of the Church] MUST be the "Surviving" individual/person; and, be "Switched", if necessary.

Once again, excluding the aforementioned, the User/Patron SHOULD ALWAYS be the one to choose who is the "Surviving" individual/person, NOT the "System".

Brett

LegacyUser

Paul said: I'm looking forward to encountering the general issue again myself! I say "again" because the message is nothing new - albeit I have not seen it for a very long time and the reason it is appearing now is possibly different from when I was having it appear. I believe my experience related to records of individuals born around 1500 and wonder if there was any connection to the fact that some of these records (either of the individuals themselves, or more probably their relatives) were locked.

I can only agree that the current issue must be related to ordinances, rather than the amount of detail (sources, relationships, etc.) on one side. I try to always put the individual with the most information on the left hand side during a merge, but have never had any problems when I have merged "the other way round".

LegacyUser

Adrian Bruce said: Locking? That's interesting... If Profile-B is locked and you tried to merge it into Profile-A, doesn't that blow the idea of locking away? You could discard all sorts of stuff from Profile-B and impose your ideas on it. Mind you, even doing it the other way round gives you the opportunity to infiltrate values into the locked profile. So this error message doesn't seem to fit that issue.

What about if it's a spouse or child or parent that's locked? Not sure then... But one would hope that the warning message was more specific in that case

LegacyUser

Adrian Bruce said: Yes - I am speculating - it's the challenge!

LegacyUser

DougHo said: Paul, I think you are correct that if a person has relationship with read-only person, then they must survive on the left-side of merge.

LegacyUser

Tom Huber said: It is my understanding that any locked profile cannot be merged in either direction. FS personnel will need to verify my understanding.

LegacyUser

Adrian Bruce said: You must surely be right, Tom.

I think Doug might also be correct. If Profile-A is not locked but has a relationship of some sort with a locked profile, then maybe Profile-A cannot be merge-deleted because that would require an amendment to the data on the locked profile to change the "pointers". Whereas if Profile-A is the survivor of the merge (on the left in a browser) then no amendments to the locked profile are necessary because the "pointers" don't change. Maybe!!!

That would fit the text of the error message. Maybe!!

But that still leaves the possibility that there are other files outside FS FamilyTree that (e.g.) contain PIDs that cannot be updated because of a merge in FS FamilyTree, requiring the merge to be a certain way round in order to make that PID survive. Maybe!!