Sanity check is a response to an issue that has been described many times in PhpGedView, webtrees, and recently in kiwitrees. The title sums up the issue well, although I can’t claim credit for it. I ‘borrowed’ it from an excellent piece of online software called “Bonkers” that operates as a stand-alone sanity checker. If you want a more in depth review of your data than kiwitrees offers, I highly recommend it. They describe the issue with an excellent quote:
Sooner or later, we all get to the point where we realize that there is a lot of data in our database that is just completely bonkers.
The intention with the kiwitrees sanity checker is to allow you to select one or more data issues you think might exist in your tree, quickly search for all examples, then click on a link to each of the records concerned to check and adjust the data as necessary.
Sanity checker is quite different to, and does not replace, the existing tool “Check for GEDCOM errors” which is designed to check your data for strict adherence to the GEDCOM specification. Sanity checker goes to the next level, checking for data entry errors that may not technically be GEDCOM errors, but do seem to be “bonkers”.
It is important to be aware that the term “bonkers” is extremely non-scientific 🙂
Bonkers does not always mean WRONG!
But at least with this tool you have an opportunity to check. Some specific examples of acceptable “bonkers data” are noted in the descriptions below.
There is an important note on the sanity checker page, in red. It says “This process can be slow. If you have a large family tree or suspect large numbers of errors you should only select a few checks each time”. Please consider this before you tick all the boxes. How many checks you can do in one go will depend on the size of your tree, the number of errors, and the amount of memory available on your server. If an error occurs a “fatal error” message will appear on the page. You can clear that by simply clicking your browser’s ‘back’ button. Then try again with fewer tools ticked. If even one tool is too much for your system either ask your webhost for more memory, or use an external tool not dependent on your server such as “Bonkers“.
The check tools are grouped by common features, such as subject matter, or error type as shown on the above screenshot. Below here each one is briefly described, and it’s basic parameters are provided to give a better understanding of what the results you get actually mean.
Some check tools have additional options (check boxes) to allow you to further refine your analysis.
Almost all these checks are calculated directly from your kiwitrees database, using complex database queries. This means that any changes you make to the date via normal record additions , deletions and edits can be immediately reflected in the check results.
Most results include links directly to the individuals or other records so you can review the issue and correct it as necessary.
The results are each displayed as a list. Most are sortable, and printable in the form of a CSV file. Custom Separated Valuescompatible with most spreadsheets
Date discrepancies
| Title | Query description | Important considerations |
|---|---|---|
| Birth after baptism or christening | Calculates the age of the person at the date of their baptism (BAPM) or christening (CHR) (whichever you use), in days. It then lists any where that age is less than zero. | If either dates are missing or invalid the individual will be ignored. |
| Birth after death or burial | Calculates the age of the person at the date of their death (DEAT), burial (BURI), or cremation (CREM) (whichever is found), in days. It then lists any where that age is less than zero. | If either dates are missing or invalid the individual will be ignored. |
| Birth after marriage | Calculates the age of the person at the date of their marriage (MARR), or non-marriage event (_NMR)(whichever is found), in days. It then lists any where that age is less than zero. | If either dates are missing or invalid the individual will be ignored. “Marriage” is only taken from the individuals’ family (FAM) record. Use of the MARR tag in their individual (INDI) record is not used. |
| Birth after their children | Calculates the age of each individual on the birth date of each of their children, from any marriages they had. It then lists any of those children where that age is less than zero. | Dates for the individual, and each child must exist and be valid or that match will be ignored. Because this requires checking every individual in a family tree, and every child from any marriages (whether actually married or not) this can be a slow process on large trees. |
| Burial before death | Calculates the age of person at both death and burial, then lists any where the difference is less than zero. | Burial and death dates must exist and be valid, otherwise the individual will be ignored. |
| Sibling age differences | Calculates the age of each child in every family on the date of birth for each of their siblings. Then lists both children for any case where their age difference is greater than 1 day and less then 9 months.. | Because this involves checking every child against every one of their siblings, across every family record in the tree, this can be a slow process. This will produce ‘false positives’ in cases such as twins born on different days; and premature births causing an age gap perhaps just under nine months. Both cases are rare, but not impossible. So don’t always assume these are errors. |
Age related queries
Each of these checks uses a specified age parameter, in years. You can change the default values to any other number of years, entered as shown below without any ‘y’ or ‘years’ etc. The new figure will be stored in the database until you change it again, or click the “Reset” button. The “Reset” button changes all parameters to the original defaults.
| Title | Default age | Query description | Important considerations |
|---|---|---|---|
| Baptised after a certain age | 5 | Lists any individual with a baptism (BAPM) or christening (CHR) date more than the default number of years after the individuals birth date. | Both baptism(or christening) and birth must have valid dates recorded, or the individual will be ignored. |
| Alive after a certain age | 120 | Lists any individual that does NOT have a death, burial, or cremation date recorded, and whose age is greater than the default number of years. | Simply have a death recorded as “yes” is not considered in this list as a valid date is regquired to calculate age at death. The default or reset date is taken from the family tree configuration setting “Age at which to assume a person is dead”. It can still be manually over-written and saved into the database, and that will not change the family tree configuration setting. |
| Married before a certain age | 14 | ||
| Being much older than spouse | 30 | ||
| Mothers having children before a certain age | 15 | ||
| Mothers having children past a certain age | 50 |
Duplicated data
The check for a duplicated name is a very specific case. It only finds duplicates where the individuals FULL name is IDENTICAL and entered twice.
Birth
Death
Gender
Name
Missing or invalid data
No gender recorded
No gender simply looks for individuals where there is no gender (SEX) recorded. It will find individuals with no SEX tag at all. It does not need to check for values other than the acceptable “M, F, or U”, nor for entries of just “1 SEX” as these are all converted to valid entries automatically on either import or edit.
These tools looks for two (or more) similar records within a single individuals data record, such as two births (BIRT), two deaths (DEAT) or two genders (SEX). It does not consider the content of those records, just their existence. While such duplication might appear to be “bonkers”, you should not assume that is always the case. The GEDCOM specification allows for recording multiple occurrences of the same event in situations where for example a researcher discovers conflicting evidence about a person’s birth event. The specification indicates that in such cases you should record each event in order of preference. Kiwitrees acknowledges this and always uses the first event as the “preferred” one.