Jump to content


Photo

Marking Living and Not Living

marking living

  • Please log in to reply
6 replies to this topic

#1 DaveConrad11

DaveConrad11

    New Member

  • Members
  • Pip
  • 2 posts

Posted 10 June 2019 - 12:02 PM

I would like to be able to make all entries after a certain date or age to be "unselected as living". This is important as we cannot always find a death for an individual and so an entry may be for a person 120 years old but still considered living. Sites such as FamilySearch will not accept an entry that is marked living. (which it is be default in RM) It is not practical to go back through tens of thousands of records to see if they are marked living or not. 

 

The power to "Mark everyone over xxx years old" to show "Not living".

 

Thanks



#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 10 June 2019 - 01:06 PM

If I understand your request correctly, RM already supports the desired functionality. Tools>Set Living>False. You then get a dialog where you can choose something like Birth>Date>Before>1910 or perhaps Any Fact>Date>Before>1010 because for example a marriage before 1910 strongly suggests the person is no longer living. You can't really select an age, but selecting a date should be good enough.

 

Jerry



#3 Kamolga

Kamolga

    Advanced Member

  • Members
  • PipPipPip
  • 69 posts

Posted 11 June 2019 - 05:17 AM

I just run an SQL query

SELECT * 
FROM PersonTable p
JOIN NameTable n
ON p.PersonID=n.OwnerID
WHERE (n.BirthYear>0 AND n.Birthyear<1900 AND p.Living IS NOT 0) 

to view who in my few thousands records where born before 1900 and alive...result is none. I am surprised since I imported my unreliable and inconsistent database to RM and keep forgetting to untick the "living" box most of the time. I conclude that RM does it automatically for me: I think the software assume the parents of a dead person are dead (I noticed that I had to come back to tick 'alive' when adding the living parent of a dead person) but do not know if they also consider a specific age or date to tick it off.


Rootsmagic 7.5.9.0 with a lot of SQL queries (SQLiteSpy) and a bit of Family Historian 6.2 (tree view and map)


#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 11 June 2019 - 07:09 AM


I conclude that RM does it automatically for me:

 

It does do it automatically for you. It's just that the automatic process is often imperfect and needs to be supplemented with with a Set Living process on your part. Also, when you do the Set Living yourself, you can control the parameters.

The automatic process seems especially problematic if you update some of your data for a person after the person is first entered into your database. The automatic process seems to be more reliable if you put all the data in when you first Add the person to the database, but often this is not possible. And indeed, the NameTable.BirthYear column you reference in your SQLite query is itself often unreliable and the problems occur most often if birth information is added or changed after the person is first added to the RM database. The NameTable.DeathYear column has the same problem. 

NameTable.BirthYear and NameTable.DeathYear are the birth and death date that are displayed in the Index sidebar on the RM screen. Either or both of these fields are often wrong, and both of them are fixed by the File>Database Tools>Rebuild Indexes process. I'm not sure what else is fixed by the File>Database Tools>Rebuild Indexes process. I know that the SQLite indexes for indexed tables are rebuilt by the process. These indexes are invisible to the RM user except that they make the database run a lot faster than it would otherwise. I don't know if the automatic Set Living is run when you to the File>Database Tools>Rebuild Indexes process.

There are a few (very few) SQLite updates that I have run that have created problems in the SQlite indexes that can be seen by File>Database Tools>Test Database Integrity. Just to be overly cautious, I therefore run File>Database Tools>Rebuild Indexes anytime I run an SQLite update of any kind, and I always seek out a non-SQLite way to accomplish a bulk update task if possible before resorting so SQLite for updating. True queries with SQLite seem to be 100% safe.

 

Jerry



#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6218 posts

Posted 11 June 2019 - 11:18 AM

My understanding is that RM's Set Living process operates solely from the comparison of today's date to a person's DoB or the existence of a death event. It sets the Living flag to True for all persons lacking a death/burial event unless their DoB is over 105 years earlier. Thus someone from centuries past would be set to Living if they had neither a death/burial nor a validly dated birth/christen event. I developed this script to address that deficiency: https://sqlitetoolsf...g-set-globally/

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 Kamolga

Kamolga

    Advanced Member

  • Members
  • PipPipPip
  • 69 posts

Posted 12 June 2019 - 01:33 AM

I update indexes manually from RM every 30 minutes or so, as well as automatically (REINDEX) after each query using UPDATE or DELETE FROM. The process takes seconds as with cleaning phantoms or testing integrity. For some reason compact database often fails (error message, does not start but the window does not leave)because of some other SQL running (which I do not see) and in such case, creating backup when closing does not work. Closing and opening RM solves the issue.

I would indeed not use name.birthyear to overwrite living=1 to 0 but extract the year from the Eventtable.

I never had any issue with the Birthyear though but I read this 'refresh' issue somewhere.

I think mine is quite reliable (never spotted any error): I imported a few thousands records from Myheritage, I therefore had only unsourced records with many mistakes, duplicates and so on. After using intern tools of RM to clean the database (merge duplicates, data clean,...) I used SQL to put 'about' (abt) in front of all the dates (and an * in the suffix of each person -> I like it because I see it in left pane and does not impact matching help) -> very quick way to see what need to be confirmed and make groups with SQL). The abt is taken out after each fact verification, the * after relationships are confirmed by a reliable source (-> if today I found an ancestor on Ancestry from a shared tree, I would enter the person with * and abt, if it is from a database record such as birth certificate, no abt and no *).  90% of the input are without the official birthyear (parents of new husband) at first, not on wedding records, but I put an est date anyway (20 to 30 years less than new husband, round up or down). All the people who had no birthday were given an estimated (est) date, so all records have a birthyear (I know if I see abt that it came from an online tree, est that it could +- 30 years and a normal date is "proved and official") -> I have no 'hole' in the year of the left pane, it is for me the quickest way to know if I should create a person or use an existing one with the same name (Joannes and Maria are given names at least once in each family ID of a branch for decades, and they had about 10 kids each). If I change the birthdate of someone (I always do it manually) and sourced, the birthyear seems to update accordingly very fine so far.


Rootsmagic 7.5.9.0 with a lot of SQL queries (SQLiteSpy) and a bit of Family Historian 6.2 (tree view and map)


#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 12 June 2019 - 06:54 AM

I update indexes manually from RM every 30 minutes or so, ......

 

I won't quote all your procedures, but they are very impressive!

 

Jerry