I think , that is a malfunction, that records like this cannot simply indentified by RM
extern tools are not recommendet
What I’m seeing is that two different people in your database have the same FSID, one with RM record number 88938 and the other with RM record number 1654, I have never seen that happen, and I can’t picture a scenario that would cause it. What happens if you go from RM to FamilySearch for each of these two individuals? Does it go to the same person in FamilySearch each time?
I would need to know more about your database to be sure, but I suspect I would just do a merge of these two people in the RM database. The merged person should still be matched properly with correct person in FamilySearch.
But I caution that I don’t know enough about your database to be sure. For example, what data is in the right most column that is cut off, where it says either Deutch or BInzwa?
Since databases (and GEDCOM files exported by RootsMagic) can contain this info. One obvious group of possibilities is a DragNDrop (GEDCOM can be used instead of DragNDrop) operation involving two distinct RM databases one to another.
It’s possible to have more than one person matched to the same FSID in RM. Especially when the records are merged incorrectly on FamilySearch. Then when you open the person in the FSPT in RM it will update the FSID to what it was merged into.
I’ve also seen people match to the same FSID using Find Matches. There is nothing to stop them. It’s a collaborative tree and many people are working on the same records. Many times you don’t realize you have the child unlinked from the parents or from their spouse and there are two records of them in the database. In the case above more than likely it’s a bad merge on FamilySearch.
2 Likes
I would look at the actual person (GF6Y-QJ5) in FS to see the information there.
I have seen many versions of this – sometimes the error is caused by FS or changes since. Sometimes it can be caused by user error and using the FSC if you are not careful.
As Jerry mentions I would be cautious – they might actual be different people that should have different FSID (or one of them unknown). Sometimes it can be very challenging to keep up with all the FSID. The design of FSC is probably the best out there - -that said it could still use improvements – but those changes / improvements would be difficult to implement for all to be comfortable with.
I would view the people also online as well as in FSC. You might need to UNMATCH and search for matches to see if there is a better fit- that might be a new match or one you did not see before.
a very simply solution/workaround will be
1), if RM can list by Filter double FSID (this shoud be by default unique) in PEOPLE view
and/or
2) if a group-rule FFSID
is “double” in addition “is blank” etc. would possible
and/ or
3) in integrity check
The database is never integer, if FSID ist not unique (per malfunktion)
this is the Field “Birth Place”
In FS is only exact one ID and the both IDs in RM are linke to this one
In der Regel verschmelze ich Personen nur in FS, da dies die primäre Instanz meine Stammbaumes ist. Die Verschmelzung wird ja dann in RM übertagen ??
Wenn ich in RM verschmelze muss ich ja händisch, die Verschmelzung in FS nachziehen.
Meine Arbeit ist nun, dass ich Familie für Familie, Person für Person im FS Browser abgleiche und dabei mögliche Duplikate in FS finde.
Das Grundproblem liegt in FS, dass man dort kein vernĂĽnftigen Tool hat, um zum Beispiel Personen mehr als ein Eltern-Paar zu finden.
Ich behaupte, dass dies bei Tausenden oder mehr im gesamten FS der Fall ist
I do not agree FSID MUST BE UNIQUE, however if & when they are not unique there should be indication (such as highlight maybe the FSID) or to be able to find them easier within RM UI. Now finding them outside of RM is fairly simple query. If know the FSID in question you can run a quick search using Adv search to find them all and who are they.
Kevin
If a person is duplicate in both RM and in FS, you have to do the merge both places. The merge in one place doesn’t automatically do the merge in the other place.
If a person is duplicate in FS and does not exist in RM, you can merge the duplicates in FS and then copy the person to RM and the person will not be duplicate in RM.
If a person is duplicate in RM and does not exist in FS, you can merge the duplicates in RM and then copy the person to FS and the person will not be duplicate in FS.
It’s actually easy in RM to find people in RM with more than one set of parents. Do an Advanced Search with a criterion of Number of sets of parents > greater than > 1. You can use the same criterion to make a group of everybody in your database who has more than one set of parents.
1 Like
das wäre ok, aber das problem ist, dass man bei 11000 Datensätzen eine solche “bad”-FSID nur durch Zufall finden kann.
Zusammenfassung:
1)
In FS ist alles bezĂĽglich der Eindeutigkeit der FSID in Ordnung .
Das ist ein Problem innerhalb RM. Es sollte deshalb auch von RM eine Möglichkeit zur Behebung möglichst mit “Bordmitteln” geboten werden
2)
jedoch das Problem mit doppelten Eltern is in FS begrĂĽndet.
In RM habe ich es mit Hilfe einer definierten Gruppe gefunden.
Da nachfolgende Problem ist, dass ich die Behebung gleichzeitig is FS (Beziehungen entfernen) und RM (Beziehungen unlinken) beheben muss .
Eine Synchronisation mit FS wäre erheblich leichter, wenn im FS-Browser die von mir vorgeschlagenen Zusatzinformationen (weitere Filter, Geburtsdatum, FS-Status erweitert) realisiert würden.
my point about duplicates is this:
You could have
RMID 900 with FSID ABC-123
RMID 800 with FSID DEF-456
they are later merged on FS then you end up with duplicates in RM even though the user did nothing wrong, Regardless of how duplicates can occurs there needs to be a better way in RM UI
Translation
That would be fine, but the problem is that with 11,000 records, you can only find such a “bad” FSID by chance.
Summary:
1)
In FS, everything is fine regarding the uniqueness of the FSID.
This is a problem within RM. Therefore, RM should also offer a way to resolve it, if possible using “built-in tools.”
2)
However, the problem with duplicate parents is rooted in FS.
In RM, I found it using a defined group.
image
image887Ă—362 14.7 KB
The following problem is that I have to resolve it simultaneously in FS (remove relationships) and RM (unlink relationships).
Synchronization with FS would be considerably easier if the additional information I suggested (additional filters, date of birth, extended FS status) were implemented in the FS browser.
1 Like
ich habe eine weitere Vermutung zum Entsehen der doppelten FSID in RM
Bekanntlich erkennt RM im Auto-Merge nur Situationen, bei denen relevante Facts EXACT ĂĽbereinstimmen, so bei places.
I had merged some here:
beim Mergen kann es wohl vorkommen, dass RM eine doppelte FSID anlegt und intern weiter als unterschiedlich behandelt, so beim GEDCOM Export