Recursive Queries – Ancestors and Descendants #recursive #ancestors #descendants

As of Feb 3, 2014 and version 3.8.3, SQLite introduced “Recursive common table expressions (that) provide the ability to do hierarchical or recursive queries of trees and graphs, a capability that is not otherwise available in the SQL language”. (http://www.sqlite.org/lang_with.html) This means it is now possible to generate ancestry or descendancy lists within SQLite, without having to resort to a higher level language. These lists can be unlimited in length, unlike queries based on earlier versions of SQLite, which required a SELECT statement for each generation (e.g. the 2011 Ancestors Query). The WITH RECURSIVE syntax is much shorter than cascading like queries and executes much faster (60ms vs 300ms, for example). While the syntax is challenging to understand, an error or change needs to be dealt with in one or two spots, not in every SELECT in a cascade. Here’s a helpful guide to gain understanding: The Simplest SQLite Common Table Expression Tutorial.

A first attempt at a recursive query was reported on Ancestors Query – Recursive. I then proceeded to develop the complement – a recursive Descendants query. Because the two are complementary and will benefit from parallel development, and because recursion is such a significant step forward in the power of SQLite, a page focussed on recursion as it applies to the two essential genealogical queries seems appropriate. This page presents an enhanced Ancestors query and its complementary Descendants query and will, hopefully, see further development.

rev 2015-11-24 Descendants: filter added for sex so that a birth only relationship for female descendants of a woman would be those sharing mtDNA from her; the complementary male line is also provided which would those sharing the Y-STR chromosome. Note that RootsMagic has in its Select People dialogs tools to mark/unmark people by genetic lines.

Ancestors

This query is fundamentally the same as Ancestors Query – Recursive with the addition of named parameters which the user defines at run-time:

  1. $BirthOnly(YN): enter “Y” or “y” to restrict the lineage to birth relationships (bloodlines); entry of anything else will include all relationships (adoptive, step, etc.)
  2. $Person(RIN): enter the record number of the person whose list of ancestors is wanted

The result is a list of the record numbers of the ancestors under the heading AncestorID and does not include the starting RIN.
AncestorsRecursive.sql

-- AncestorsRecursive.sql
/*
2014-04-14 Tom Holden ve3meo
 
Generates the list of RINs for the ancestors of a person.
 
Requires support not only for SQLite 3.8.3 or later but also
for named parameters for user input of the RIN of the starting person
and choice of birth only or all relationships.
 
Developed and tested with current SQLite Expert Personal 3.5.36.2456
 
Uses the WITH RECURSIVE syntax introduced in SQLite 3.8.3 2014-02-03
modelled on http://www.sqlite.org/lang_with.html example
and complement of DescendantsRecursive.sql
*/
 
WITH RECURSIVE
  parent_of(ChildID, ParentID) AS
    (SELECT PersonID, FatherID AS ParentID FROM PersonTable
       LEFT JOIN ChildTable ON PersonID=ChildTable.ChildID
       LEFT JOIN FamilyTable USING(FamilyID)
       WHERE
         CASE $BirthOnly(YN)
         WHEN 'Y' OR 'y' THEN RelFather=0
         ELSE 1
         END
         --RelFather=0 --birth father (ELSE WHERE 1 to include all relationships)
     UNION
     SELECT PersonID, MotherID AS ParentID FROM PersonTable
       LEFT JOIN ChildTable ON PersonID=ChildTable.ChildID
       LEFT JOIN FamilyTable USING(FamilyID)
       WHERE
         CASE $BirthOnly(YN)
         WHEN 'Y' OR 'y' THEN RelMother=0
         ELSE 1
         END
         --RelMother=0 --birth mother (ELSE WHERE 1 to include all relationships)
     ),
  ancestor_of_person(AncestorID) AS
    (SELECT ParentID FROM parent_of
       WHERE ChildID=$Person(RIN) --enter RIN of starting person at runtime
     UNION --ALL
     SELECT ParentID FROM parent_of
       INNER JOIN ancestor_of_person ON ChildID = AncestorID)
SELECT AncestorID FROM ancestor_of_person, PersonTable
 WHERE ancestor_of_person.AncestorID=PersonTable.PersonID
;

Descendants

This query is a complement to the Ancestors query, structurally very similar, and with the same named parameters which the user defines at run-time:

  1. $BirthOnly(YN): enter “Y” or “y” to restrict the lineage to birth relationships (bloodlines); entry of anything else will include all relationships (adoptive, step, etc.)
  2. $Sex(MF?): enter one of “MmFf) to restrict the lineage to males or females only; anything else includes both.
  3. $Person(RIN): enter the record number of the person whose list of descendants is wanted

The result is a list of the record numbers of the descendants under the heading DescendantID and does not include the starting RIN.
DescendantsRecursive.sql rev 2015-11-24 filter added for sex so that a birth only relationship for female descendants of a woman would be those sharing mtDNA from her. The code following is the original query.

-- DescendantsRecursive.sql
/*
2014-04-14 Tom Holden ve3meo
 
Generates the list of RINs for the descendants of a person.
 
Requires support not only for SQLite 3.8.3 or later but also
for named parameters for user input of the RIN of the starting person
and choice of birth only or all relationships.
 
Developed and tested with current SQLite Expert Personal 3.5.36.2456
 
Uses the WITH RECURSIVE syntax introduced in SQLite 3.8.3 2014-02-03
modelled on http://www.sqlite.org/lang_with.html example
and complement of AncestorsRecursive.sql
*/
 
WITH RECURSIVE
  child_of(ParentID, ChildID) AS
    (SELECT PersonID, ChildTable.ChildID FROM PersonTable
       LEFT JOIN FamilyTable ON PersonID=FatherID
       LEFT JOIN ChildTable USING(FamilyID)
       WHERE
         CASE $BirthOnly(YN)
         WHEN 'Y' OR 'y' THEN RelFather=0
         ELSE 1
         END
         --RelFather=0 --birth father (ELSE WHERE 1 to include all relationships)
     UNION
     SELECT PersonID, ChildTable.ChildID FROM PersonTable
       LEFT JOIN FamilyTable ON PersonID=MotherID
       LEFT JOIN ChildTable USING(FamilyID)
       WHERE
         CASE $BirthOnly(YN)
         WHEN 'Y' OR 'y' THEN RelMother=0
         ELSE 1
         END
         --RelMother=0 --birth mother (ELSE WHERE 1 to include all relationships)
     ),
  descendant_of_person(DescendantID) AS
    (SELECT ChildID FROM child_of
       WHERE ParentID=$Person(RIN) --enter RIN of starting person at runtime
     UNION --ALL
     SELECT ChildID FROM child_of
       INNER JOIN descendant_of_person ON ParentID = DescendantID)
SELECT DescendantID FROM descendant_of_person, PersonTable
 WHERE descendant_of_person.DescendantID=PersonTable.PersonID
;

To Do’s

  1. Update previous queries that used the old cascaded Ancestors query, e.g., Ancestors Named Group
  2. Create new queries based on these simple lists of ancestors and descendants, e.g. Named Groups and Color Coding
  3. Investigate how one might add collateral lines
  4. How might one apply the ancestry query to clearing the Living flag for ancestors of persons who should be dead.
  5. Add generation number to results of ancestors and descendants – useful for reports
  6. Add FamilyID to results

Source Templates – Versatile Free Form Hybrids #sourcetemplates #sources

Introduction

This query introduces a radical variation on RootsMagic’s system of Source Templates. It combines Source Templates and Free Form properties into Versatile Free Form Hybrid Source Templates incorporating the best of both worlds. Sources built on older source templates will now have free form fields that can be used to create alternative sentences that will survive GEDCOM export better than the templated sentences. Sources built on Free Form are not changed but can now be converted losslessly to templated sources, the data values being transferred from the Free Form source to the Free Form-like fields in the Hybrid source. And new sources built on the Hybrid templates can begin either in Free Form or template style while the other can be created and edited from within the common Edit Source window.

This idea sprang from discussion on Jerry Bryan’s page Question with respect to Changing a Master Source to a Different Source Template.

Conversion from ordinary templates to Versatile Free Form Hybrid Source Templates

Screenshots

SourceTemplatesHybridFreeFormConvert-EditSrc1.PNG
Source using a Hybrid built-in source template showing the default output sentences coming from the original template fields, not the added (FF) fields.
SourceTemplatesHybridFreeFormConvert-EditSrc2.PNG
Same source but the FORCE FF field non-empty value causes the sentence outputs to come from the (FF) fields.

Restoring after Drag ‘n’ Drop to new database

Transfer of sources, based on built-in templates that have been so Hybridized, to another RM database initially appears to lose the Free Form fields. However, the data values were transferred and merely running the query on the other database will restore the transferred sources to the Hybrid state.

Conversion of Free Form sources to Hybrids

Conversion of Free Form sources to Hybrid templates is possible and not difficult. You need to replace the TemplateID value of 0 for specific sources in the SourceTable to the TemplateID value of the desired Hybrid template. The (FF) fields will be populated by the values of the Free Form source. If that template does not work out, you can readily change the source to another Hybrid template and not lose the (FF) values from which you parse values for the template fields.

Feedback

This query is EXPERIMENTAL – try it on a copy of your database. See if it works for you. Let me know what you think, what works, what doesn’t. For those who have used !MyFreeForm3, I suspect there will be complications that will be precluded in a later version – after all, I use it, but this initial version was developed on just the built-in source templates. who

Future Considerations

A later version will add the fields from !MyFreeForm3 for even better Free Form style sentences and another utility could toggle the ForceFF field to control which sentence template is used for export, i.e., Free Form for export, templated for reports and other outputs.

Download SQL Script

SourceTemplatesHybridFreeFormConvert.sql rev 2013-12-17: !MyFreeForm3 templates no longer converted; speed tweaks.

Script

--SourceTemplatesHybridFreeFormConvert.sql
/*
2013-12-16 Tom Holden ve3meo
2013-12-17 rev1. no longer converts !MyFreeForm3 templates
           rev2. possible speed up by reducing use of CAST
Marries source templates up with Free Form for the best of both worlds:
a) use the templated part as an input form to help draft a Free Form source
b) paste a citation from Ancestry, FamilySearch et al into the Free Form part to
refer to while populating the template fields.
c) toggle between sentences outputted from either the Free Form fields or the
templated fields
 
EXPERIMENTAL
The revised templates have added fields in Free Form style (FF) and a Force FF field
that determines whether the sentences outputted are from the Free Form fields or
the template fields.
 
N.B.: the built-in source templates, while converted, will not transfer
to another database. Because the target database has only the templated fields
in the template definitions, the Free Form fields will appear to be lost. Running
this utility on the target database will make them reappear with the values in
each source intact.
 
*/
 
-- backup SourceTemplateTable builtin templates (you could revert to this version
-- after executing the query the first time)
 
DROP TABLE IF EXISTS xSourceTemplateTableBak
;
CREATE TABLE IF NOT EXISTS xSourceTemplateTableBak AS
SELECT * FROM SourceTemplateTable
;
 
/*
-- Restore from backup
INSERT OR REPLACE INTO SourceTemplateTable
SELECT * FROM xSourceTemplateTableBAK
*/
 
DROP TABLE IF EXISTS xTmpUnconvertedTemplates
;
CREATE TEMP TABLE xTmpUnconvertedTemplates
AS
SELECT TemplateID , CAST(FieldDefs AS TEXT) AS FieldDefsTxt
FROM SourceTemplateTable
;
DELETE FROM xTmpUnconvertedTemplates -- delete the already Hybrid templates or !MyFreeForm3 templates
WHERE
    (
     FieldDefsTxt LIKE '%<FieldName>ForceFF</FieldName>%' -- ForceFF is added by Hybrid
     OR
     FieldDefsTxt LIKE '%<FieldName>ShortPage</FieldName>%' -- ShortPage is added by !MyFreeForm3 which does not need conversion
     )
;
 
-- Convert Source Template FieldDefs to Hybrids
UPDATE SourceTemplateTable
SET FieldDefs =
CAST(
     REPLACE(CAST(FieldDefs AS TEXT), '<Fields>', '<Fields><Field><FieldName>Footnote</FieldName><DisplayName>Footnote (FF)</DisplayName><Type>Text</Type><Hint>footnote sentence from Free Form source, without the source detail</Hint><LongHint/><CitationField>False</CitationField></Field><Field><FieldName>ShortFootnote</FieldName><DisplayName>Short Footnote (FF)</DisplayName><Type>Text</Type><Hint>short footnote sentence from Free Form source sans source detail</Hint><LongHint/><CitationField>False</CitationField></Field><Field><FieldName>Page</FieldName><DisplayName>Page (FF)</DisplayName><Type>Text</Type><Hint>page value from Free Form source, originally the source detail</Hint><LongHint/><CitationField>True</CitationField></Field><Field><FieldName>Bibliography</FieldName><DisplayName>Bibliography (FF)</DisplayName><Type>Text</Type><Hint>bibliography sentence from FF source</Hint><LongHint/><CitationField>False</CitationField></Field><Field><FieldName>ForceFF</FieldName><DisplayName>FORCE FF</DisplayName><Type>Text</Type><Hint>Any value will force Free Form (FF) sentences</Hint><LongHint>If left empty, the sentences will be generated from the template fields below this field. If non-empty, the sentences will come from the Free Form-like fields above this one or designated (FF).</LongHint><CitationField>False</CitationField></Field>')
     AS BLOB)
WHERE TemplateID IN (SELECT TemplateID FROM xTmpUnconvertedTemplates)
;
 
/*
Some templates already had a [Page] field so now they have two and one must go
The only one we can be sure of having a constant pattern is the one we just added
so we delete it.
*/
UPDATE SourceTemplateTable
SET FieldDefs =
CAST(REPLACE(CAST(FieldDefs AS TEXT)
     ,'<Field><FieldName>Page</FieldName><DisplayName>Page (FF)</DisplayName><Type>Text</Type><Hint>page value from Free Form source, originally the source detail</Hint><LongHint/><CitationField>True</CitationField></Field>'
     ,''
     )
     AS BLOB
    )
WHERE TemplateID
IN(
   SELECT TemplateID
   FROM  xTmpUnconvertedTemplates
   WHERE FieldDefsTxt LIKE '%<DisplayName>Page</DisplayName>%' -- template already having a [Page] field
   )
;
 
/*
Convert Source Template sentence templates to Hybrid
e.g. Footnote: <? [ForceFF]|[Footnote], [Page].|--originalfootnote--|[Footnote], [Page].>>
*/
UPDATE SourceTemplateTable
SET
Footnote =
REPLACE(Footnote, Footnote, '<? [ForceFF]|[Footnote], [Page].|' || Footnote || '|[Footnote], [Page].>')
,
ShortFootnote =
REPLACE(ShortFootnote, ShortFootnote, '<? [ForceFF]|[ShortFootnote], [Page].|' || ShortFootnote || '|[ShortFootnote], [Page].>')
,
Bibliography =
REPLACE(Bibliography, Bibliography, '<? [ForceFF]|[Bibliography].|' || Bibliography || '|[Bibliography].>')
WHERE TemplateID IN (SELECT TemplateID FROM xTmpUnconvertedTemplates)
;
 
/*
Done.
*/

Set Hybrids to Free Form for Export to GEDCOM

By using well both the (FF) fields and the more specific template fields for each source, you have both a quality sentence conforming to Evidence guidelines for use in reports AND a sentence that exports well to GEDCOM from the same source. It’s necessary to Force the (FF) sentence to be outputted, otherwise, the default is the source-specific template sentence. One does so by putting any value into the FORCE FF field. This query looks for any sources that have a non-empty Footnote (FF) sentence and an empty FORCE FF field and puts the value “GEDCOM” into the latter. Any sources already forced to output the Free Form sentence are untouched. Sources that have empty Free Form Footnote fields are also left unchanged.

Download

Sources-HybridFF-SetFF-Export.sql

Script

-- Sources-HybridFF-SetFF-Export.sql
/*
2013-12-17 Tom Holden ve3meo
 
Sets Hybrid Free Form Templated Sources to output the Free Form footnote,
if not already so set, using the value "GEDCOM" in the ForceFF field.
 
The complementary script sets those Hybrid templates with "GEDCOM" in the
ForceFF field to output the templated sentence, as would be desirable for all
other destinations, such as reports.
*/
 
DROP TABLE IF EXISTS xTmpHybridSourcesSetFF
;
CREATE TEMP TABLE IF NOT EXISTS xTmpHybridSourcesSetFF
AS
SELECT SourceID, CAST(FIELDS AS TEXT) AS FieldsTxt
FROM SourceTable
WHERE CAST(FIELDS AS TEXT) LIKE '%<Field><Name>ForceFF</Name><Value/></Field>%' -- empty FORCE FF field
AND CAST(FIELDS AS TEXT) LIKE '%<Field><Name>Footnote</Name><Value>%'  -- non-empty Footnote (FF) field
;
 
UPDATE OR REPLACE xTmpHybridSourcesSetFF
SET FieldsTxt =
REPLACE (
         FieldsTxt
         , '<Field><Name>ForceFF</Name><Value/></Field>'
         , '<Field><Name>ForceFF</Name><Value>GEDCOM</Value></Field>'
         )
;
 
UPDATE OR REPLACE SourceTable
SET FIELDS =
(
SELECT CAST(FieldsTxt AS BLOB) FROM xTmpHybridSourcesSetFF
 WHERE SourceTable.SourceID = xTmpHybridSourcesSetFF.SourceID
)
WHERE SourceID IN (SELECT SourceID FROM xTmpHybridSourcesSetFF)
;

Set Hybrids to Source-Specific Sentences (Unset Free Form) for Reports et al

After having run the above query to set sources to export the Free Form sentences, you will want to reset them back to outputting the source-specific or source template sentences for most other uses. This script looks for all the FORCE FF fields having the value “GEDCOM” and empties them. It won’t touch those sources that have some other value in the FORCE FF field – for example, you may have sources for which you prefer the Free Form sentences to those using the source-specific fields.

Download

Sources-HybridFF-UnSetFF.sql

Script

-- Sources-HybridFF-UnSetFF.sql
/*
2013-12-17 Tom Holden ve3meo
 
Sets Hybrid Free Form Templated Sources to output the templated or non-Free Form
sentences, if set to output Free Form by the value "GEDCOM" in the ForceFF field,
as would be desirable for all other destinations, such as reports.
 
The complementary script sets those Hybrid templates with an empty ForceFF field
to output the Free Form sentence by adding setting the ForceFF field to "GEDCOM".
*/
 
DROP TABLE IF EXISTS xTmpHybridSourcesUnSetFF
;
CREATE TEMP TABLE IF NOT EXISTS xTmpHybridSourcesUnSetFF
AS
SELECT SourceID, CAST(FIELDS AS TEXT) AS FieldsTxt
FROM SourceTable
WHERE CAST(FIELDS AS TEXT) LIKE '%<Field><Name>ForceFF</Name><Value>GEDCOM</Value></Field>%'
;
 
UPDATE OR REPLACE xTmpHybridSourcesUnSetFF
SET FieldsTxt =
REPLACE (
         FieldsTxt
         , '<Field><Name>ForceFF</Name><Value>GEDCOM</Value></Field>'
         , '<Field><Name>ForceFF</Name><Value/></Field>'
         )
;
 
UPDATE OR REPLACE SourceTable
SET FIELDS =
(
SELECT CAST(FieldsTxt AS BLOB) FROM xTmpHybridSourcesUnSetFF
 WHERE SourceTable.SourceID = xTmpHybridSourcesUnSetFF.SourceID
)
WHERE SourceID IN (SELECT SourceID FROM xTmpHybridSourcesUnSetFF)
;

Children – Set Lineage to Birth #birth #ancestors #lineage

RootsMagic 7 and prior has the peculiar shortcoming that ancestral lineage reports, charts and other important functions follow the lineage set by the parent family displayed in the last view of each person in one of the Main screens. If the last time you viewed your mother showed her stepfather as her father, then her birth father’s line is completely omitted while the stepfather’s line is included. This affects several reports and charts:

  • Ancestor narratives
  • Ahnentafel
  • Ancestor Box Chart
  • Pedigree Chart
  • Photo Tree
  • Ancestor Wall Chart

Moreover, it also affects the filter for selecting ancestors of the highlighted person in RootsMagic Explorer’s Mark/Unmark Group functions used for

  • other reports
  • GEDCOM export
  • colour coding
  • Named Groups

RootsMagic provides no option for any of these to be directed to follow the birth line despite having the feature in the Edit Person window to set the type of relationship between a child and a parent couple to other kinds such as adoptive or step. There seems to be little point to the Relationship setting because it is visible only in the Edit Person screen and is otherwise totally ignored. There has been a long outstanding Wish List item for the system to put the relationship setting to effective use.

Meanwhile, here is a potentially useful script if you have the typical family tree with several people having more than one parent couple and want to restore the focus to the birth line without having to manually search for those with other relationships to ensure that their Main View is set to the birth parents. It has been tested on a small trial database so, as always, be sure you have a backup before using it on your database or try it on a copy of your database. If you have the same database open in both RootsMagic and the SQLite manager from which you ran the script, you will not see any effect in RootsMagic until you refresh the Main Screen by switching to a different View.

Children-SetLineage2Birth.sql

-- Children-SetLineage2Birth.sql
/*
2015-10-18 Tom Holden ve3meo
 
Sets the displayed lineage to that of the Birth parents so that
lineage views and reports follow the birth line.
In the case of multiple birth parents (permitted by RootsMagic),
sets the birth family to the one with the highest Proof setting,
else to the lowest FamilyID.
 
It does not (or cannot?) cover all possible combinations that
a user might wish to allow or consider to be the preferred lineage
because a parent family (couple) may have only one member (mother
or father) and each spouse of a couple may have any of the four
proof settings for the birth relationship (0-undefined, 1-proven,
2-disproven, 3-disputed).
 
*/
 
DROP VIEW IF EXISTS BirthCouple
;
-- this view of the parents includes only birth parents in descending order of proof
CREATE TEMP VIEW BirthCouple AS
SELECT  ChildID, FamilyID FROM ChildTable
WHERE RelFather = 0 AND RelMother = 0  -- birth relationships
AND ProofFather < 2 AND ProofMother < 2  -- relationship proof is proven or undefined
ORDER BY ChildID, ProofFather DESC, ProofMother DESC -- priority to 'proven' relationships
;
 
-- set the display lineage to the birth parents with highest level of proof and
-- do not touch persons with no parents
UPDATE PersonTable
  SET ParentID =
    (SELECT FamilyID FROM BirthCouple BC
       WHERE PersonID = BC.ChildID)
  WHERE PersonID IN (SELECT ChildID FROM BirthCouple)
;
 
-- the temporary SQLite View BirthCouple will be deleted when the SQLite
-- manager closes the database

Ancestry.com and RootsMagic 5 #ancestrycom #sources #update #gedcom

Problems with GEDCOM

In my experience, building an evidence-driven Family Tree on Ancestry.com
from evidence found in its databases is faster and easier than extracting
the evidence from Ancestry.com and building the documented tree in
RootsMagic. But my RootsMagic database remains superior in other respects
and is my master database for reporting. So I have a number of problems
marrying my Ancestry and RootsMagic family trees and synchronizing them:

  • excessive exception report from the GEDCOM import
  • no images downloaded and linked
  • verbose footnotes

Avoid Glut of
Unknown Info _APID on Import

When you import into a RootsMagic database a GEDCOM downloaded from an
Ancestry Family Tree, RootsMagic generates an exception report file with the
.LST extension and with the same name and the same location as the database.
It is filled with a glut of exceptions of the form:

Unknown info (line 28)
    3 _APID 1,8944::212

These obscure the more interesting exceptions. Since RootsMagic does not
import these _APID lines, deleting them from the GEDCOM prior to import is
harmless while clarifying the LST resport. I use this regular expression
global search and replace in PSPad to clean them out:

Find: ^.+_APID.+$
Replace:

For the tree that is the subject of this page, it deleted 4461 occurrences
of the _APID tag from the GEDCOM.

Getting
Source and Other Images from Ancestry.com

The GEDCOM that you download from an Ancestry Family Tree does not contain
any images but it does include a URL to the Source page for each citation
that RootsMagic imports into its Citation Comments field. Conversely, Family
Tree Maker 2012 can synchronise with the Ancestry Family Tree and downloads
all the images; however, it is a bloated, slow program and does not include
the Ancestry source page URL in its export to GEDCOM 5.5 despite providing
the path to the local image file. Importing both GEDCOMs into a common
database and merging duplicate persons sounds plausible and easy but proved
useless. To re-marry the URLs
and the media items in a RootsMagic database, I developed the following
merging procedure which appears to be about 95% successful.

  1. Import the GEDCOM from the Ancestry Family Tree (optionally cleaned of
    _APID tags) to a new RootsMagic database named “AncestryGED.rmgc” (or
    whatever suits you).
  2. Optionally, inspect the corresponding LST file and make any changes in
    the RM database that you feel are important. However, these may be lost
    as this database is secondary in the merging process that follows.
  3. Using Family Tree Maker 2012, create a FTM database by synchronising
    to the Ancestry Family Tree.
  4. Export from FTM a GEDCOM 5.5, choosing FTM 2012 as the output format.
  5. Import the FTM GEDCOM into a new RootsMagic database named to suit
    you.
  6. Optionally, inspect the corresponding LST file for exceptions and make
    possible corrections in the RM database. This will be the primary
    database in the merge so these corrections should be preserved.
  7. Open SQLiteSpy with the fake RMNOCASE extension and open the primary
    database, the one created from importing the FTM2012 GEDCOM.
  8. In SQLiteSpy open the following SQL file which you will have
    downloaded to your scripts folder. MergeAncestryURLsToFTM.sql
  9. Edit the ATTACH command line so that the path and filename corresponds
    to that of your secondary database, the one created by importing the
    GEDCOM downloaded from Ancestry.com.
  10. Execute the script. It is slow because of the many matches and string
    processing to be done and the final status report is misleading as it
    only reports the number of records converted from Name citations unused
    by RM to Personal ones.
  11. Inspect your primary database to see that your citations now include
    the URL to the Ancestry source page in the Detail Comments and that the
    media item, if it existed before, is still there.
  12. You may now proceed to Shrinking
    Verbose Master Sources from Ancestry.com

The media are all stored in one folder under the Documents > Family Tree
Maker folder (assuming a default installation). Should you relocate them,
you will need to use RM’s global Search and Replace on multimedia filenames
or its Repair Broken Media Links tool to restore connections. I’m unsure of
the implications for the longterm if you wish to continue terr-building and
synchronising on Ancestry. Will existing names be preserved? Note that a
typical name is 1891 England Census-14.jpg or
1900 United States Federal Census-2.jpg, i.e., the source name with
a serial suffix when there is more than one image from the master source.
I’m inclined to leave them where they are, names unchanged, in the hope that
FTM will download only new images and continue the serial numbers.

Shrinking
Verbose Master Sources from Ancestry.com

One problem is that citations from Ancestry are extremely verbose. So I
tackled this one first. Having examined both the GEDCOM from Ancestry and
the imported results in RootsMagic, I elected to make the revisions
post-import as that had a more obvious solution for the tools and knowledge
I have.
My strategy is to replace the RootsMagic Footnote field value with the
ShortFootnote field value and the latter with the Master Source name. The
Bibliography value remains untouched and provides the same detail as the
original Footnote. Below is a comparison of a revised Master Source with its
original. Note that both exhibit a truncation that is the fault of
Ancestry.com.

Master
Source imported from Ancestry.com

Footnote:
Ancestry.com,
1870 United States Federal Census (Online publication – Provo, UT, USA:
Ancestry.com Operations, Inc., 2009. Images reproduced by
FamilySearch..Original data – 1870 U.S. census, population schedules. NARA
microfilm publication M593, 1,761 rolls. Washington, D.C.: National
Archives and Recor)

Short
Footnote:
Ancestry.com,
1870 United States Federal Census

Bibliography:
Ancestry.com.
1870 United States Federal Census. Online publication – Provo, UT, USA:
Ancestry.com Operations, Inc., 2009. Images reproduced by
FamilySearch..Original data – 1870 U.S. census, population schedules. NARA
microfilm publication M593, 1,761 rolls. Washington, D.C.: National
Archives and Recor.

Repository:

Ancestry.ca

http://www.Ancestry.ca

Master
Source after SQLite procedure

Footnote:
Ancestry.com,
1870 United States Federal Census

Short
Footnote:
1870
United States Federal Census

Bibliography:
Ancestry.com.
1870 United States Federal Census. Online publication – Provo, UT, USA:
Ancestry.com Operations, Inc., 2009. Images reproduced by
FamilySearch..Original data – 1870 U.S. census, population schedules. NARA
microfilm publication M593, 1,761 rolls. Washington, D.C.: National
Archives and Recor.

Repository:

Ancestry.ca

http://www.Ancestry.ca

Procedure

This involves multiple steps and tools:

  • SQLiteSpy
  • PSPad or other text editor with sorting capability
  • MS Excel or, possibly, other spreadsheet program, using AncestrySourceConverter.xlsx

The steps comprise:

  1. 1. Download the Ancestry GEDCOM or export it from the synchronised
    Family Tree Maker database in GEDCOM for FTM16 format.
  2. 2. Import the GEDCOM to a new RM database.
  3. 3. Backup your database.
  4. 4. Make a copy of your database with a different name.
  5. 5. Open the new database with SQLiteSpy.
  6. 6. Run the following
    query: SELECT SourceID, Name,
    SUBSTR(CAST(Fields AS TEXT),41) AS Fields FROM SourceTable;
  7. 7. Select all results and copy to the clipboard (select a cell,
    Ctrl-A, Ctrl-C)
  8. 8. Paste into a new text file in PSPad
  9. 9. Sort and/or edit so that the headings are at the top and the
    results are contiguous with no intervening blank lines. Copy all.
  10. 10. Open AncestrySourceConverter.xslx with MS Excel.
  11. 11. Delete all from sheet Source.
  12. 12. Paste from clipboard into the 1st cell of sheet Source.
  13. 13. Copy all UPDATE queries from sheet SQL. Note that just the first
    100 queries are created. If what you pasted into sheet Source is more
    than 100 rows, you will either have to do the UPDATEs in multiple
    batches or extend the rows of formulae in sheets Extract, Replace and
    SQL.
  14. 14. Paste into a new SQL window in SQLiteSpy.
  15. 15. Check through to the end that syntax colouring is correct. If
    there was an apostrophe in the original source it will need to be
    escaped with a second so that it is not interpreted as a text delimiter.
  16. 16. Execute the batch of UPDATE queries. This may take some 20 seconds
    – I do not know why it is so slow.
  17. 17. Open both the unprocessed and revised RootsMagic databases with RM
    and inspect the Master Source list to satisfy yourself with the results
    and make any other edits required.

To abbreviate the Short Footnote more, I think requires manual editing of
each citation, most effectively done by converting the sources to the !MyFreeForm3 source template.

Images of Results

MergedURLs&Images-CitationScreen.PNGMergedURLs&Images-MediaScreen.PNG

Generate WebTags from
the Citations

This applies to RootsMagic 6 which first introduced WebTags. The Ancestry
GEDCOM passes the URL (hyperlink) of each online citation in the citation
Comments field. For convenient access to these online sources, it is
desirable to make a Citation WebTag with that URL. That’s what is described
in WebTags
– from Ancestry.com and FTM
. And then to make it even more convenient,
copy those citation WebTags to person WebTags using WebTags
– Consolidate
.

Revealing
Citations from Ancestry that Disappeared

We think that citations in support of a Name in an Ancestry tree disappear
on import to RootsMagic in certain cases. See Citations
Invisible Revealed
for further details and how to reveal them to
RootsMagic.

Discussions & comments from Wikispaces site


ve3meo

Comment: “Open SQLiteSpy with the fake
RMNOCASE extension”

ve3meo
03
September 2018 19:40:01
ve3meo Sep 28, 2015
A Mac user encountering an error “LIKE pattern too large” or
words to that effect wanted to know if there was a way to run
the script without the RMNOCASE collation (on his own build of
sqlite3). The answer is a qualified “maybe” and it will take
trial and error. Wherever there is a field that is compared to
a value and that field has been defined to use the RMNOCASE
collation, it is probable that an error will result.
It is possible in some cases to override the defined collation
with a COLLATE NOCASE suffix wherever the field is named in a
SQL SELECT statement. However, you cannot UPDATE such a field.
Fortunately, the script does not UPDATE a field using the
RMNOCASE collation so any collation error must stem from a
comparison.
However, looking into this question raised some others. A
field that is UPDATEd is CitationTable.Comments and a puzzling
thing was observed. The script assumes that it is a TEXT field
which is what is contained in a number of databases inspected
yet in the table definition it is supposed to be type BLOB.
SQLite3 does not enforce field types and it appears that
RootsMagic does not follow its own field spec. This may be a
red herring but it could give rise to unexpected results if
some databases or rows within a database were not
type-consistent with others.

SQLite Question – SELECT WHERE IN #sql

Here’s a pretty dumb question. Why will the following extremely simple query not return the desired results? I’m trying to see the sentence templates just for the birth, death, marriage, and burial facts.

SELECT FT.FactTypeID, FT.Name, FT.Sentence
FROM FactTypeTable AS FT
WHERE FT.Name IN ('Birth','Death','Marriage','Burial');

To get the desired results, I instead do something like the following.

SELECT FT.FactTypeID, FT.Name, FT.Sentence
FROM FactTypeTable AS FT
WHERE FT.Name IN ('Birth','Death','Marriage','Burial')
AND FT.Name NOT LIKE '%Bann'
AND FT.Name NOT LIKE '%Contract'
AND FT.Name NOT LIKE '%License'
AND FT.Name NOT LIKE '%Settlement';

In effect, the IN operator is acting like it’s using LIKE rather than =. So it’s picking fact names I don’t want such as Marriage Bann, etc.

Jerry

Discussions & comments from Wikispaces site


ve3meo

Not seeing your problem

ve3meo
05 June 2015 19:29:42

I ran your first query using SQLiteSpy and it returned the desired result.

Tom

Places – Conversion of Place Details to Places #places #placedetails #update

So you have your Place List all nicely structured having worked through and split Places into Places and Place Details and it all seems ticketyboo. Now you need to export your database to some other website or software which does not support the way RootsMagic exports Place Details and POOF! – you’ve been caught in another proprietary feature trap. Wouldn’t it be nice if RootsMagic had an option in Export for Place Details and Place to be combined and outputted as standard GEDCOM PLACes recognised by every GEDCOM compliant program? Until that happens, here is a possible workaround that modifies the data in your database.

Places-ConvertPlaceDetailsToPlaces.sql rev 2015-05-15 changed EventTable.SiteId backfill from -1 to 0 and test from <>-1 to >0; correcting either an original error or responding to a change in the RootsMagic value for an event not having a Place Detail.

Combines Place Details and Master Place into Places. This script should run with any SQLite3 manager having a (fake) RMNOCASE collation. One of its effects is to set a flag in the combined Places that the following script can use to reverse the combination.

Places-UnConvertPlaceDetailsConvertedToPlaces.sql
For those combined Places with the flag set by the first script, this one splits the Place into Place Detail and Master Place. The flag disappears if the combined Place has been edited so such Places can only be split manually. Also, if the Master Place has been deleted or its name modified, then the Combined Place is not split by the script, except, possibly for those Master Places that are a substring of the original, in which case, the result will be a bit of a mess. This script is really an UNDO to provide an escape if you inadvertently ran the first script on your master database, not on a copy, and have no backup.

TMG to RootsMagic Migration #tmg

This page provides an overview of the utilities available on this wiki that may help you with your migration of a TMG Project to a RootsMagic database. An example of what TMG Refugee Mike James did is described at https://lists.rootsweb.com/hyperkitty/list/tmg-refugees.rootsweb.com/thread/199856/. It is important to note that there may be considerable cleanup and data manipulation to be done in TMG first in order to have as complete a data transfer as possible because RootsMagic does not replicate all the features of TMG.

These pages have been tagged “TMG” because they apply to artefacts in databases imported from TMG:

Of course, once your TMG data is in a RootsMagic database, you are able to apply any of the 200-some SQLite queries available here and to develop your own.

Marriages, Length of #marriage

This script answers the question, “How long have marriages lasted?”. For each Marriage and corresponding Annulment or Divorce event for a couple,
it extracts the year of the events and also gets the year of the death of the earlier of the two to have died. It then calculates the length in time between the year of the marriage event and the earliest of the years of the Annulment, Divorce and Death events as the length of the marriage. In the absence of a year for any of these terminal events, it uses the current year from system time. Results are limited to 99 years max.

MarriageLength.PNG
Screen clip of results of query on a small test database in SQLiteSpy.

The second last row in the example is the special case of a couple that divorces and remarries each other; the Length of the second marriage is correct but the Divorced year throws a curve visually. It could be suppressed with a some more coding but is a rare state.

The Died year comes from the Person’s DeathYear field in the NameTable, not directly from the Death or Burial facts, so it is advisable to use File > Database Tools > Rebuild Indexes before running the script to ensure that the DeathYear is sync’d to the latest edits or additions of Death/Burial events.

When there are multiple events of a given type, this script probably extracts the year of the first entered; it could be enhanced to select the Primary.

MarriageLength.sql

Ancestors Query #pedigree

Intro

This query lists all the ancestral lines for a given RIN in your database out to the 13th generation. It is just a table of RINs but could be extended to provide names et al. More significantly, it can be the basis of other queries that need to follow ancestral lines. One of these, already developed is Ancestors Named Group which refreshes the membership of a specially named group in a RM4 database.

AncestorsScreenshot-Spy.PNG
From SQLiteSpy showing the full ancestral lines for three persons plus part of a fourth. Use SQLite Developer or Expert Personal to specify the starting person’s RIN when the query is run – absolutely necessary for large databases.

There was earlier discussion about the need for program recursion for ancestral lines in Set Living Flag and in Another version of a Set Living query. This query does not achieve recursion as it seems quite likely that it cannot be accomplished within SQLite; a higher level language making calls to SQLite seems necessary. However, the script appears amenable to programmatic generation so that instead of recursive calls to SQLite, a dynamic script itself could be written to cover the desired number of generations. RootsMagic 4 may do it either way as the number of generations is a required input.

No attempt was made to filter on the type of relationship (blood, adoptive) between child and parent so the results include all kinds of ancestry.

Download

Ancestors.sql

Usage

This query uses a runtime parameter for the entry of the RIN of the person whose ancestral lines are to be generated. If left blank, or if your SQLite manager does not support runtime parameters, it will attempt to generate the ancestral lines for EVERYONE in your database. This will be very sloooow and may crash the program. SQLite Expert Personal and SQLite Developer ($29 version) do work with the runtime parameter; SQLite Spy skips over it.

Discussions & comments from Wikispaces site

ve3meo

Comment: “…the need for program recursion for ancestral lines …”

ve3meo
03 September 2018 19:37:05

ve3meo Mar 28, 2014

SQLite 3.8.4.1 and somewhat earlier introduced the WITH clause with the RECURSIVE option which should allow ancestral queries in a tree. The current version of SQLite Expert Personal supports this new clause but SQLite Spy does not.
ve3meo Mar 28, 2014

My first success with recursion in SQLite: Ancestors+Query+-+Recursive

Children – Set Order by Birth SortDate #child #family #sortdate #update

There have been recurring wishes expressed in the RootsMagic Forums for an enhancement to globally sort each family of children in the order they were born. For example, have a look at this thread, Sorting all children in the database by birth order. Expressed there are good reasons to be cautious about such an operation but, for some users, the possibility of adverse positioning of children without dates is outweighed by the time saved in organizing those who do. Until RootsMagic does offer such a feature, here is a script that sorts children by birth date.

While executing the script is straightforward, the underlying procedures involve several temporary SQlite Views and a temporary Table. It tries to pick out the dominant event for a person from his/her collection of Primary and non-Primary Birth and Christening events. A single Primary Birth with date is handled best; multiple Primaries or multiple events of the same type in the absence of a Primary may give an undesired order if dates overlap with another child.

The script only updates the child-sorting value (ChildTable.ChildOrder) of those children with a birth-type event having a SortDate and only for those families in which all children have said SortDate. The ChildOrder value of other families is left unchanged. Thus, it should be safe to use this script on a database for which some families have children lacking a birth-type fact or a SortDate for same; it will not affect the order of children whether they are still in the sequence they were added to the family or were subsequently manually rearranged.

To find families which still need to be rearranged manually after having run this script, see Children – Needing Manual Arranging.

It is the SortDate of the birth-type event which is the sorting key, not the Date. This means that users can enter a Birth fact without a Date or with a text Date (unrecognised date format) but with a SortDate estimated to be appropriate and what they might have in mind were they manually rearranging the children. The child order would then be reconstructed correctly by the script.

Almost any SQLite3 manager should be capable of executing this script. As usual, make a backup or work on a copy of your database file so you can get back to where you were before the script executes if you don’t like the outcome.

Children-SetOrderByBirthSortDate.sql
2015-01-22 1st release
2015-01-22 rev to preserve the order of children in families where 1 or more have no birth sortdate or no birth fact.
2015-01-24 rev to correct the override of valid Christen SortDates by empty Birth SortDates