I do not want you to think that the unknown and unknown parent problem is the only one that can cause your broken links moving up and down the generations. I was only pointing out that if that particular case is identified it will cause duplication of the unknown and unknown parents that you should be aware will happen. The unknown and unknown parents are the only ones which I am aware of that will be duplicated without warning after an intellimerge however. If there is one real parent then in my testing there will not be a false duplication of parents after an intellimerge.
Brian Customer Support Millennia Corporation br...@legacyfamilytree.com http://www.LegacyFamilyTree.com We are changing the world of genealogy! When replying to this message, please include all previous correspondence. Thanks. On 03/03/2011 8:01 PM, britton...@comcast.net wrote: > Brian, > > I had assumed a mechanism of that kind, but more seems involved. As you have > put it, outcomes have to be or tend to even and quantized to powers of two. > My last major cleanup had numbers to the low/mid 60s by estimation, which did > seem clustered to roughly approximate by keystrokes while dismissing "unknown > and unknown" parents to zero, finding no (simple) 20-70s, and all the large > blocks in the low/mid 70s, spanning about 72-76. No simple doubling scheme > works to get that. > > What also showed up were cases where upward traversal truncated and the > parent was present but embedded, i.e. with multiple "unknowns and unknown" > both above and below. More telling were a few cases where a parent and a > parent set were both embedded and separated. The parent sets were from the > missing spouse being found and added in one file, probably the right hand one > in the Intellimerge. > > Unlike in the major cleanup mentioned, this last one had very few couples > with the multiplied spouses, (identical RINs, one being asterisked, the order > apparently always matching). None had "unknown and unknown" complications, > but that could be happenstance. Dennis' good catch on bad screen refresh did > lead to another perhaps revealing datum though. It impelled me to examine > the unrelated RINs for link damage, none being found, but RIN 210 was paired > with an "unknown", so I dismissed her after noting that that would unlink her > from husband and child. After dismissing hundreds of others, mostly parent > pairs, plus fixing duplicate pairs, as a last check, I ran Treefinder - and > there was RIN 210 as an isolate. Apparently dismissing an "unknown" spouse > breaks the other's links too, or the child was only linked to "unknown". > > The logical and digital expression of "unknowns" raise some questions. I > don't know how Legacy and gedcom work, but digital considerations may require > space reservation for pointers and that they have targets. Logically, since > children commonly have two parents, "unknown and unknown" seems redundant. A > single "unknown" may be needed though to indicate child relationship to an > unknown parent, distinguishing from those of named - or similarly unknown > ones. Both logically and digitally, that leads to different classes and > properties for "unknowns", e.g. a tree or branch head without parents merges > quietly, but one with "unknown" ones apparently breeds them. Broadly a useful > logical division might be "signaling" and "silent". (For programmers, see > NaNs and their complexities.) > > Legacy might have been better designed assigning UID numbers to "unknowns". > Certainly, if Legacy automatically assigns an invisible "unknown" to partner > an unpaired parent if a child is linked, and silently breeds pairs of them > with minimal warning, that's either a bug or at least deserving of written > explanation and warning. A simpler alternative might be to simply include > purge of all redundant "unknowns" during File Repair, though multiple and > embedded parent sets are problematic. Best, obviously, would be acting at > data entry time, but it may be too late for that. > > kb Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyusers.com/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
