19th December 2017 at 6:21 pm #9713
A challenge for you:
I just ran this check and did find some interesting situation:
> child born and dies; additional child born afterwards and named the same
Hence the duplicity is valid and I’d like to have this family ignored when regenerating list. Along the “ignore in future” checkmark. That way, future runs for the same request will only show those that I still need to find who the kids are (referring back to sources). I know the request as presented isn’t feasible but possibly there is some method that would be.
----- [updated: 06 Feb 2022] MacOS: 10.15.7 (Catalina) Safari 14.1.2; Firefox 96.0 PHP 8.0 FastCGI; mySQL 5.x
Alter-Drukarsh Connections 3.3.10b/the Garelicks <family members only>
The Royals | The Kennedys |The Gerrer Rabbis 3.3.10b <.rbcsolutions.ca>
20th December 2017 at 4:58 pm #9719
An interesting suggestion, and not a new one. The thought has occurred to me even back in PGV days. Then (and now) it was in relation to Batch update > Add missing married names. I run it regularly because I often forget to add them when I find marriage details. But I have about 10 or more examples (mainly name changes, adoptions etc) where I do not want a particular “suggested” married name to be added. So I must remember to skip each of those and always run the update one record at a time.
There are now a lot more examples in the “Sanity check” tool that could use a similar “ignore this one next time” feature.
But that is where the problem becomes unmanageable, and why I don’t think I will ever do it.
For such a setting to work, it must be possible to record a “don’t update” flag against the relevant record. By “record”, I mean it could possibly be any of INDI, FAM, OBJE, SOUR, or NOTE, although INDI and FAM are the most obvious uses. In addition, there would need to be a different flag for each check. One for duplicate names, one for married young, one for children at an older age, and so on. Potentially there could be as many as 25 different flags set for any single individual or family.
That raises the issue of processing efficiency and speed. I don’t think this could easily be done as a database stored item, because currently when anyone re-imports a GEDCOM file it deletes all existing data (for that tree). So all those flags would be removed! So it would need to be something like a series of “unofficial GEDCOM tags”, like _DUPE_NAME, _MARR_YNG, etc.. Perhaps 25+ of them.
Ultimately, that just gets too messy, I’m afraid. So I am going to, reluctantly, say no to this idea, at least until a better / more practical solution comes to either my mind or anyone else who has a suggestion.Nigel
My personal kiwitrees site is www.our-families.info
- The topic ‘Sanity Check: duplicately named children’ is closed to new replies.