Home Page list
Pulling Together All the Events for An Individual #person #events #lifeline
This discussion was started around the Database System Catalog page and all posts up to its continuation on this page can be reviewed in full here
In summary, MarkVS posed this problem:
One thing that I wanted to do, and I expect might be of interest to others, is to be able to
stream all the events for an individual and then, depending on what reporting I wanted to
do, sort and/or group and/or filter the records accordingly.
From what I have learned to date it appears to be neceesary to run three separate queries
and combine the results to get the "complete" datastream. These are the queries I think
1) Firstly the straightforward one. The Events held on the Event Table for individuals need
to be pulled off. It is important to select only those with an OWNERTYPE of 0. You can link
to the various other tables from this data to pick up the FactType description, name of the
person etc etc, as required.
2) Secondly, the family events. These are also held in the Event Table but with an OWNERTYPE
of 1. This means that the event being recorded acutally applies to 2 people. So to get this
data into a stream of events you need to take the value of the OWNERID field and use this to
look up the record in the FAMILY table (ie not the PERSON table as you would if the OWNERTYPE
was 0). In the Family table you will see the Husband and Wife ID and these can be used to pick
up the names of the two people to whom the event applies. Then in theory generate an Event
into the data stream for both of them.
3) Thirdly we need to pick up Shared events. These are recorded in the Witness table. This
holds the Person ID to link back to the Name of the person and the Event ID to link back to
the Event record (and from there to the fact description etc etc).
romermb responded with a query design based on a UNION of five SELECTs, demonstrating the use of constants and NULLs in the SELECT fields to build a uniform results set from each SELECT allowing the UNIONs to append the result sets together.
One of the five early queries is extracted below, showing the constant 'Principal' and NULL being used to fill columns to correspond with the layout of the other queries; COLLATE NOCASE being used to replace the RMNOCASE collation sequence that must be embedded in the RootsMagic software and unavailable to third party SQLite managers; COUNT and GROUP BY to flag and skip duplicates. This version was revised by ve3meo with explicit use of INDEXED BY and NOT INDEXED clauses to override sqlite's query optimiser which was found to adversely affect the speed of this set of queries by a factor of ~1000, in the worst case. Later versions avoided this deprecated practice by hiding the IsPrimary field from the SQLite query optimiser so that it would not choose a slow index; one slight change in the WHERE clause is all that is needed: +
The current version is extensively revised from the original and is compatible with a wider set of SQLite managers plus OpenOffice Base than was version 9 and runs as fast or faster. It incorporates facts for individuals, couples, parenting and shared facts with fairly comprehensive date reporting. Now includes persons not in a database tree but named as having a role at an event for a person in a tree.
UNION ALL -- add all events for Individual
Facttypetable.Name COLLATE Nocase ,
Nametable.Surname COLLATE Nocase ,
Nametable.Suffix COLLATE Nocase ,
Nametable.Prefix COLLATE Nocase ,
Nametable.Given COLLATE Nocase ,
COUNT( 1 )
Eventtable NOT INDEXED INNER JOIN
Facttypetable NOT INDEXED ON Eventtable.Eventtype = Facttypetable.Facttypeid INNER JOIN
Nametable INDEXED BY Idxnameownerid ON Eventtable.Ownerid = Nametable.Ownerid
Eventtable.Ownertype = 0 AND Nametable.Isprimary = 1