I have not paid attention to the Living checkbox when adding a person. My database is about 60k people but likely only 100 are ACTUALLY Living. Of the rest, if there is a death date it seems that RM is smart enough to figure out they are NOT actually living. But for some of them I dont have death data and they still appear to be living even though their children were born and died int he 1700 and 1800’s. Is there a way to get RM to sort through that and update the Living flag a little more sensibly? I can search for people with the Living flag - True and that is so many pages of results I cant even count it!
RM does not check children birthdates to determine whether to unset the living flag. It only looks at any birth information entered for the parent. If the birth is 120 years from present, then the flag is automatically unset. If you have no birth information, it will be a manual process.
The “Set Living” functionality can change the flag to false using Mark under the Select People
Ahh, thanks, had not noticed that tool.
Now I just need to create the right groups.
I have about 60k people and all are NOT living except about 100 or so. Some of those 100 are in fairly distant branches (9th cousins and the like) and I cant think of any reasonable way to select them into a group and maybe not even easy to FIND all of them in the database. Any ideas?
The Set Living tool is very useful and it’s also very limited. For example, if you have a bunch of people born around 1700 with parents who do not have a Birth fact, then it can be very hard to use the Set Living tool for those parents.
I have a long term (and very slow) project to be sure that everybody in my database has a Birth fact with some sort of reasonable estimate of their birth date. I may not get the project done in my lifetime. But if I do, it will make the Set Living tool work much better for my database.
That has been a longstanding shortcoming of the RM Set Living function. Jerry and I have dabbled at more comprehensive tools using sqlite3 which culminated with this one:
https://sqlitetoolsforrootsmagic.com/living-flag-set-globally/
It probably works with RM9.
It’s too bad that the RM developers have not incorporated its logic in the built-in Set Living tool.
1 Like
I should have known you’d have a script, Tom! I read through your precis of the steps it follows and it certainly covers many bases. The greatest case for me is probably some 4-5 generations ago, people with birth/death dates, but I have only the names of their parents (from a marriage register perhaps) - and your script would catch them.
But do you think it would handle this case — I have some cousins who are 7th, 8th, 9th cousins. I can follow my line back to our common ancestor and then down a different branch to get to them. I will have details for some of the generations working down that other branch but probably run into “just names, no dates” before I get to the remote cousin. Hard to guess when the “must be dead by now” assumptions could kick in to set the flag correctly in those cases.
It might help if I knew which “Living = true” people were left untouched by the script and then perhaps I could make the effort to work through them manually afterwards … if it’s only 1 or 2 thousand names! (See Jerry’s note about a long term project {grin}).
Isn’t the more serious risk that the Living flag is set False for someone who is really still alive? If you can make a group of the 100 or so you know to be alive or there’s a chance they could be, you could readily check them after any bulk operation.
I don’t doubt that the logic may skip setting some False because the distance from a key event in their lineage is too great. You could tinker with parameters in the script but the real key is establishing reasonable dates for some facts.
Good luck!
1 Like
Probably correct Tom. It’s a little tedious to manually find the 100-ish people out of 60k names but once in a group then I can set Living = false for the entire database and set Living = true for this special group. Not something one would have to do very often! Thanks for the chat.