Baptism for the Dead
This is primarily for LDS users of Ancestral Quest, because it shows how to find people who have not been baptized. For those who have a non-LDS FamilySearch account, the process works about the same way, but it happens faster. Non-LDS accounts skip the step where they check to see what ordinances have already been performed for these people. It is a good way to find possible collateral “cousins.”
Have you, as a parent, a youth leader or as a youth, ever been asked to provide a list of names of people for baptisms for the dead? How could you create such a list using Ancestral Quest? This is how I would do it. We’ll start with a new dedicated file containing no records. We will first import the descendants of a person we have pre-selected, Dennis Eidson. On your file, this would be some direct line ancestor, possible an end-of-line person, about whom you have reliable documentation. The instructions which follow assume you have already gone through the login process.
We click on the FamilySearch tab and select Import Family Lines.
We click on Download Descendants of FamilySearch Person, and enter his FS PID. We specify how many generations to download, and click on Import. I use 7 because I want a large file for demonstration purposes. If you are at a FamilySearch Library, or Family History Center, you will probably not have enough time to wait for that large collection of records. I suggest only 3 or 4 generations until you see the dynamics of your particular family.
Ancestral Quest asks us to verify that we want to import Dennis Eidson and up to 7 generations of his descendants, so we click Yes.
Family Tree begins sending us the requested records, and Ancestral Quest builds the file and makes the correct family linkages. This is where we wait patiently. Family Tree will send the records of Dennis Eidson, and all of his deceased descendants, which are in the Family Tree. Ancestral Quest keeps us informed about where it is in this process.
Here is the same screen after about an hour and a half of processing. Two hours? I didn’t really time it, so this is a guesstimate. Compare this with the screen immediately above it. After importing the first ten records, Ancestral Quest was estimating an expected 151,273 records. In the more recent screen, 4,020 records have been imported, and the estimate has dropped to 8,296. if we had requested only one generation of descendants, AQ would have started with an estimate of 12 people, two parents, five children, and five spouses. If we had requested two generations of descendants, AQ would have added five children to each of those married children couples, 25. Each child would be expected to have a spouse, another 25, so AQ would have estimated 62 people. For each family with more or fewer than five children, the estimate needs to be re-calculated for all of the remaining generations. Here we show that we are importing someone from the 6th generation of descendants, and the blue bar has moved almost half of the way across the window. For each generation you add to the request, you can expect approximately a doubling of the number of records to be returned, and the time it will take to do it. The key word here is approximately.
Now the process of importing names is nearly complete. At that point, non-LDS accounts will be ready to start removing duplicates from this file in preparation for comparing it to their actual file. I would recommend using this file as a source for hints. Do your own research on the accuracy of what you find.
If you have an LDS account, this process will begin. Each imported name will be checked against the record of ordinances performed, and that information will be inserted into your AQ file. This does not currently include Confirmation or Initiatory ordinance information. I timed this process, and saw that in 60 seconds, 50 records were updated. This could vary with the amount of activity on the FamilySearch system, and possibly with the speed of your internet connection. In theory, I can expect about four more hours of processing before this file is completely updated. You may want to download fewer than 7 generations. At the end of this process I didn’t get a picture the screen which reports the time used and how many ordinance updates were completed, but it took a long time, and it did lots of work.
Now we want to find which of the people in the new file need baptism. It will help to have a permanent record, so we will build a report to list them. The things we need to think about are that they must be eligible to be baptized or endowed, not yet baptized, the gender we want, and born before 1905. It is 2015 at the time this is being posted, so that accounts for the 110 year rule. We will first define the report. Note the blue numbers by the red boxes. These indicate the order in which I will do things.
Starting with (1) at the top, the Printer Icon will bring up the Reports and Charts menu. We will click on the (2) Custom tab so that we can select the fields and the sort order for the report. We will change the (3) Title to “Males Eligible for Baptism.” Next we will select the (4) Fields to show on the report, and the (5) Sort Order. When we know what the report will look like, we can (6) Select the proper records. We want this to be a (7) Text File, so we push that radio button. This allows us to place the .txt file on the Desktop for future reference. At that point, we will be ready to (8) Print the report, which in our case will write it to a file on the Desktop.
Steps 4, 5 and 6 are easier to understand if you see how it is done, so here is step 4. Click on Fields.
On the Report Fields screen, the (1) Vertical Slider allows you to browse through the list of Possible Fields. The (2) Greater Than button allows you to move Possible Fields to the Selected Columns list. When you have selected the fields for the report, click the (3) OK button.
Next, back on the Reports and Charts menu, click the (5) Sort Order button.
Click on RIN and use the Greater Than button to tell AQ to sort the report into RIN order. Click OK.
Now, back on the Reports and Charts screen, we are ready to let AQ select the records we want, and report them to us. Click on (6) Select.
We are going to tell AQ how to select records for the report. Click Define.
The Field Filtering screen is where we tell Ancestral Quest how to select the records for our report. Use the Vertical Slider to find the fields to be examined. Use the Greater Than button to move fields from the Possible Fields list into the Current Filter list. The first field we need to examine is near the bottom of the Possible Fields list, Qualified for Baptism/Endowment. We want to include people who are qualified for individual ordinances. Highlight that item, and click the Greater Than button to include it in the list of filtering statements. Select IS. We have more filtering statements, so we click on AND, and click Greater Than. We want to follow the 110 year rule, so from those already accepted, we narrow it down to those born earlier than 1905. Use the Vertical Slider to find Birth Date, and highlight it. Click the Greater Than button. From the pull down menu select Is Less Than, and enter 1905. We have more conditions to narrow the list, so highlight AND, then click the Greater Than button. The first filtering item on the list accepted people who are qualified for either baptism or endowment or both. We want to exclude those who have already had a baptism and are awaiting endowment. Use the Vertical Slider to go down the Possible Fields list to LDS Baptism Date. Highlight that item and click Greater Than. On the pull down menu, select Does Not Exist. There is one more thing we will probably want to do to narrow down the list, so add AND to the list. These lists are typically to be used by someone in the Young Men or Young Women organization. These are gender specific, so we will use the Vertical Slider to find Sex. Highlight that and click Grater Than. Here we can select Matches Male or Matches Female. For demonstration purposes, we will select Matches Male.
Our list is narrowed down to those we want on the report, so we will Save this list. That way we can Retrieve it and use it again at some future date when more records are in our file, or possibly with a different file. Give the selection criteria a name, and click Save. We are returned to the Select Set of Individuals screen, where we click OK.
Ancestral Quest found 225 males qualified for baptism. Click OK, and return to the Reports and Charts screen. We want the report to go to the Desktop, so be sure that the (7) Text File radio button is selected, and click (8) Print.
We want to see the report, so click Yes.
When you select a .txt file, AQ writes it in CSV format. CSV is an acronym for Comma Separated Values. This type file can be imported into a spreadsheet. If we had elected to Preview or Print the report instead of creating a .txt file, it would have looked like this.
This would be a good time to check into the quality of the information you have received. Did the previous submitters have sources to verify the information they have entered? Are date ranges consistent with the records to which they are linked? Are you convinced by what you see that the information is reliable? Can you provide source information which is missing on the records you have downloaded?
Now that we have a list of those who are initially qualified according to the data in our AQ file, we need to go through the procedure for reserving the baptismal ordinance. It is likely that some of the names on our report will not be qualified from the point of view of the church. There are multiple reasons why this might be the case. The person you downloaded into your .aq file may have one or more duplicate records on the Family Tree. One or more of these duplicates may have already received baptism. Part of the reservation process is to merge duplicate records on the Family Tree. The person you downloaded or another person on the Family Tree whom you merged with your linked person may not have an LDS Baptism Date, but that ordinance may have been reserve by someone else and not yet performed. In that case, the Family Tree software will not allow you to reserve that ordinance. I am telling you this so that you will understand why you should next select more than the 10 or 15 records you want to place on an FOR, Family Ordinance Request. We don’t know how many will be in this situation, so to make a list of 10 to be baptized, we will select the first 30 from our report. The RIN for the first person is 18, and the RIN for the 30th is 2818.
Here we will click on Reserve Ordinances.
We want to use our previously defined set of criteria, so click on Add Selected Local Record(s).
To do that we will select Advanced Filter/Focus.
We need to retrieve our selection criteria, so we click Define.
We will retrieve the Filter we saved before.
We scroll down to the the filter we created, Qual4BaptMale, highlight it, and click Open.
This is the filter which gave us our report, but now we want to narrow it down to the first 30 people on the report.
We insert another AND, and highlight RIN in the Possible Fields list. Click on Greater Than, and enter the range from 18 to 2818, which represents the first 30 people on the list. Click OK.
Thirty records have been selected. Click OK.
Ancestral Quest begins retrieving the current temple status on each record.
We see that all but 4 of the records still have no baptism date, and are eligible for baptism in the church’s point of view. Now we begin the process of reserving baptisms. We start by highlighting the first name which indicates it can have baptism reserved, and we click Check for Dups.
I see nothing to convince me that this is the same person, so I click Close.
Ancestral Quest shows that I have checked for duplicates, so I click Reserve.
We note that the ordinances will be assigned to Me. This means that any ordinances we reserve will not be released to temples for them to perform. They will remain on my reserved list. We check the boxes labeled Baptism and Confirmation, then we click Reserve.
If we are not aware of Church Policies governing reservation of ordinances, we can click the View Church Policies button and read them. After you have read them, you click the I have read… button, then click Continue.
Ancestral Quest shows that these ordinances are on my reserved ordinance list, and that they are ready to be selected to be placed on an FOR. I continue highlighting names, checking for duplicates and reserving ordinances.
I have found a person with a matching record on Family Tree. This is a duplicate of the record to which I have linked for this person, and I need to merge them in the Family Tree. I click the Match box, and click Merge. I could have had more than one matching record. In that case I would have clicked the Match box for the next matching record, and again clicked Merge. I would continue that process until I found no more matching Family Tree records.
I agree with the actions that will be taken, so I Merge the two Family Tree records. I attempt to reserve ordinances, but…
…I see that the baptism and confirmation were already completed on the record which I merged, so I click Cancel.
Ancestral Quest shows that the ordinances are Complete, and does not mark the record as Ready to be included on an FOR. I continue checking for duplicates and reserving ordinances until I have the 10 that I needed for my list.
When that is done, I go to the bottom of the Reserve Ordinances/Create Batches screen and click Create FOR. The church will create the FOR and send it to your computer. Print it, and take it to the temple.
Before you leave, click on the Remove button, and click the All Records (Start Over) radio button, and Remove them from the Reserve Ordinances list. This will speed up using the Reserve Ordinances/Create Batches screen next time.
Suggestions/Questions about AQ Will Do or Subjects discussed here? Leave a Comment Below. I would like to hear from you!
This applies only to those with an LDS Login to FamilySearch Family Tree. Others will receive the message invalid_grant error during login to FamilySearch: 400. The purpose of this function is to update ordinance information in the local AQ or PAF file, so that it reflects new ordinance activity in Family Tree.
To access this function, do the following:
Click on the FamilySearch tab, and select Ordinance Reservation and Tracking System, (ORTS). You will then see this screen:
Select the Update Ordinances option.
This is the Update LDS Temple Ordinances screen. Use the Records to Update box at the top to select which records you want to test for update. This shows that All has been selected, and reports the number of records to be tested. There are four check boxes in the section below the Records to Update box. Check the first if you want to bring information about Confirmation and Initiatory ordinances into your file. The next box is used to place the words In Progress into the ordinance date for ordinances awaiting completion. I prefer to retain the date of submission. The third check box tells AQ to create a report of all changes made to your database during this process. I always select this option. The last check box is used to let AQ know how to handle the situation where Family Tree records corresponding to records in your file have been merged, and their FS PID changed. When records are merged, a new record is created with a new FS PID. All ordinance activity for that person is now stored with that new FS PID.
The acronym API means Application Program Interface. An API includes the rules by which information from one computer system are to be transferred to another. The LDS Church writes the API which governs access to their databases. Under the API for the older nFS system, if a person on your file is linked to the Family Tree, and later is merged with another, a new record is created with a new FS PID, but your local file does not know about the new ID number. When you accessed ordinance information under that system, what was returned was the information as it was prior to the merge, for the record to which you were linked. Under the new FSFT API, if you attempt to access that information with the older FS PID, the church returns an error with no explanation as to why. The correct procedure is for AQ to first ask if the old FS PID has changed. If it has, the church will return the new FS PID, and AQ will update that value in your file. AQ will then update any individual ordinance information which needs to be updated. If your record deals with a family, as most do, it is more complicated. Each family member must also be queried to see if their FS PID has changed. This about doubles the time required to process each member of the family.
If you run the Update Ordinances procedure once a month or less often, there is a fairly high probability that you are linked to an individual whose record has been merged with another, and you will not receive any new ordinance information for that person, if you have not checked the box. It is up to you to determine how often you will run this procedure with this box checked on your file.
Now, back to the Records to Update box:
By clicking the Selected radio button, you will access the currently selected records from the focus filter. This is likely to have zero records selected. In any case, click the Select button.
Here I will define a query which will reduce the number of records presented to the Update Ordinances function. I will click the Define button.
I want to work with deceased persons who were born more than 110 years ago. (See 110 Year Rule) I also want them to have at least one ordinance date missing, and…
…I want them to be qualified for at least one ordinance. I could click Save, and give a name to this query, and then I could retrieve it for use again at some later date. In this case I will just click OK.
AQ determines how many records meet those specifications, and I click OK.
I am ready to continue, so I click on Update Ordinances.
AQ finds the first record with a change in an ordinance, and reports it to me. I have the option of skipping the update, updating this record only, or updating all records which have updateable information about ordinances. I choose to Update All.
I alter the name of the report to include the date in YYYY-MM-DD format so that I can see a history of my updates in chronological order, and I click Save.
AQ works through the selected records, adding any changes to the report it is creating. When it finishes…
…it tells me how many records were updated…
…and presents me with a log of the before and after values for fields that were changed.
Suggestions/Questions about AQ Will Do or Subjects discussed here? Leave a Comment Below. I would like to hear from you!
Yes, sources are an often discussed and often disputed subject. How should I document things? Should I use Notes for my documentation? Do I really want to save all those images of documents? Is there a better way?
I hesitate to suggest that what I am about to present is ‘The Best Way’ to do documentation, but I find it useful, particularly when I want to be able to view the actual online documents from which I draw my information.
As an example, I will use findagrave.com, because I typically look there for hints about other family members, location of the burial, confirmation of birth and death dates and places, etc. Since FindAGrave is an online source, I want to be able to link to it from my Ancestral Quest file. There are several steps which I take in preparation for using FAG as a source.
First, let me say that I listened closely to the instructions given by Gaylon Findlay in the Quick Start Video Tutorial. He gave some reasons why I should always record place names as City, County, State or Province, Country. (Go to the section titled ‘Quick Start – Entering a‘ and skip down to about 4 minutes and 30 seconds.) I like standardization. I like the concept of being ‘user friendly’ in my approach to genealogy. By that I mean that I try to remember that not everyone in this world speaks English, and they don’t all know that MI is the postal abbreviation for Michigan, not Minnesota, and that MS is the abbreviation for Mississippi, not Massachusetts. In other words. I try to remember to NEVER use abbreviations for place names. I also try to remember that even if the name of the cemetery is the same as the name of the city or county in which it is located, there is no place for a cemetery name in the four level structure of City, County, State or Province, Country. Therefore, I create an event which I call Cemetery. In this event I store the Date of burial. I also store the Place of the burial as City, County, State, Country. In the first Description field, I store the name of the cemetery. In the second, I store the plot number of the grave. I create the codes for the event sentence as follows:
%1%<T (%T)> was interred%4 at the %7 cemetery%<5 %@ %5>%<6 in %6>%<0, plot: %0>.
If you like the sentence this produces, feel free to copy this line of code, and use it in your own file. For information on building these sentence codes, link to Event Sentences.
I create a source called FindAGrave.
I set the Quality to ‘2=Secondary Evidence/Rec. After Event,’ because few people do as I have done, and enter THEMSELVES into FindAGrave before they pass on. I guess I would have to leave it as a 2 anyway, because after my death, I will not be here to enter the death date myself. I will leave instructions telling my family how to do that.
In the Attachment window, I create a link to the FindAGrave webpage. (See the Attachment box on the Edit Source screen above)
I also create a Repository record for my FindAGrave source.
Now that I have the event and source ready for use, I can attach them to deceased members of my file.
I look for a record of a deceased person who lacks FindAGrave documentation. For this, I highlight that person in the Name List view or the Family view, and click on Internet -> Search Favorite Sites, and select my home grown FindAGrave search…
…passing along the first and last name of the deceased, the birth or christening date and the death or burial date. FindAGrave does the search for me, and returns…
a pointer to the record of the deceased. I click on the name.
Notice the top line of the image above. That’s the URL. The problem is that it is more than just an address. It is a search key which causes FindAGrave to search for the record. Now look at the bottom line of the image. There is where you will find the Memorial number which is the Key to the FindAGrave record. I prefer to use the URL which goes directly to the record instead of searching all over again. I copy the Memorial number from the last line, and click on Begin New Search.
I paste the number into the Memorial #: field and click Search.
This returns the same record, but the URL listed at the top is a direct link to the FindAGrave record, and bypasses the search. In terms of computer time, it is much faster, and easier on the FindAGrave server. This is a service to others, since you won’t be able to tell the difference yourself.
Now we get to the actual documentation. Bring up the Edit Individual record for this person.
Go to the Other Events for this person and click the Add button.
Scroll down to your Cemetery event and click on the Select button.
Fill in the Date of burial, Place of burial, 1st Description as the Cemetery name, and 2nd Description as the burial Plot if it is listed, or if you know it. If it has been entered into FindAGrave it can be found at the bottom of the Burial location. In this example there was no Plot information listed.
Next click on the Source button.
Highlight FindAGrave as the desired source, and click the Select button.
In the Vol/Page/Film # field, I place the notation “Memorial=‘ followed by the memorial number. I could have placed it in the Reference field, but the information from Vol/Page/Film # goes into the footnotes in the documentation of reports, and the Reference number does not.
Next I highlight the URL in the FindAGrave record, and Copy it to the clip board. Go back to the Citation screen, and click the Attach button.
The Scrapbook screen shows the default Item Type as Photo. Click on the pull down arrow, and select Other…
…then paste the URL into the Filename or URL field. Click on OK, OK, OK. That’s right, once on each of three screens as you navigate back out of this procedure.
Some day, Gaylon will find time to fix the calculations of the place name so that it truncates properly, and lets you see the name of the cemetery in the description field. Click on the Save button.
If you go back to the Edit Individual screen, highlight Cemetery in the Other Events box, and click on Edit, you will get the Cemetery event screen. If you then click on the Source button, you will see the Source Citation screen. Here you can click on the View button, over on the right side of the screen, and be linked directly to the FindAGrave record for your deceased person.
I am a member of a Yahoo Group called AncestralQuest. It is a discussion group for people who use the Ancestral Quest program.
You can find this group by starting Ancestral Quest, clicking on the Internet tab and selecting Ancestral Quest Home Page.
From there, click on Community and select AQ User Groups.
Recently, one of the group members was discussing a census record. On this record was information about a man, his wife, and their family. There was evidence from other records that they were married in 1884. There was also evidence that the woman had only six children. The problem was that the census record showed a seventh child with the husband’s surname, and listed as a son, but he was born in 1880. The assumption was made that this was the son of the father in a previous marriage, and that the wife in the first marriage was unknown.
There were two problems perceived by the group members. They were described as:
1) Ancestral Quest will not allow you to create an UNKNOWN spouse the way PAF will.
2) There is no way to properly show the relationships of children to parents in more than one parental family.
I have taken records from my own family file where these relationships also exist, and I will show how to create these families in Ancestral Quest. I will also show why you should convert your PAF files to the AQ file format.
The first problem
1) Ancestral Quest will not allow you to create an UNKNOWN spouse the way PAF will.
The unknown person in this case is the assumed first wife, who is the mother of the child born in 1880.
It is easy to get into the habit of always doing things the same way. We create a marriage, then we add the children. To create a second marriage for one of the spouses, we highlight that person and we either click on Add Spouse, or we press <CTRL> U. Both of these processes open the Add Spouse for… screen. Here we have the option to create a record or click on Search for Existing Spouse…. Neither of these options allows us to create a marriage with only one spouse.
The proper way to do this is to first find or create a record for the ‘seventh’ child. Next we need to create the family and attach the child to the only parent in that family. In Family view, with that child as the primary person, click on Add Father or Add Mother, depending on which one is documented.
In my file I have a father, Marr Dixon Simons, and a mother, Helen Anna Hunt. Helen Anna Hunt had only three children. Marr and Helen were married 18 Jun 1924.
I also have a child, Ruth Simons, a daughter of Marr Dixon Simons. She was born 26 Mar 1916. For now let’s assume that she is the daughter of an unknown mother in a previous marriage. With her record highlighted, click on the Add Father text.
Her father is Marr Dixon Simons, and his record is already in my file, so I click on the Search for existing Father… button.
This brings up the Find Father for… screen, where I click on the Search for Individual… button.
This brings up the Search for Father for… screen.
Here I highlight the name of Simons, Marr Dixon, and click on the OK button.
This brings up the Add Father for… screen where we select Add Marriage. This will place Ruth into a family with Marr as the father, but no wife, yet. Click on the OK button.
We now show Ruth as the daughter of Marr Dixon Simons, with no mother. I’ll click the arrow button next to the name of Marr D Simons to move him to the primary position.
Here I open the pull down window to show all of the spouses of Marr Dixon Simons. This shows that Marr Dixon Simons has two marriages. One is with Helen Anna Hunt, and the other is with UNKNOWN. There is no RIN associated with the UNKNOWN wife, and she doesn’t have an Individual record.
In reality, Ruth Simons is the daughter of Marr Dixon Simons in a previous marriage. That marriage was with Elsie Marie Nott. She is also in my file, so I will create the relationships in Ancestral Quest, to reflect reality.
I want to change from an UNKNOWN mother to Elsie Marie Nott in this marriage, so I click on the Add Mother text.
This brings up the Add Mother for… screen. Here I could create the record for Ruth’s mother, but she is already in my file, so I click on the Search for Existing Mother… button.
Here I want to find Elsie, so I click on the Search for Individual… button.
I highlight her name, and click the OK button.
Ruth is now shown as the daughter of Marr Dixon Simons and Elsie Marie Nott. I want to see any other marriages for Elsie, so I click the arrow next to her name to move her to the primary position.
Here I see that after her divorce from Marr, Elsie married Arley Call George.
The second problem
2) There is no way to properly show the relationships of children to parents in more than one parental family.
Here I want to switch to a PAF file format, to show the advantages of the AQ file format. I will move Ruth to the primary position to show her relationship to her parents. I will click on the Other Parents/Rels button.
This shows that Ruth is the biological daughter of Marr and Elsie. What it does not show is that she was not raised by her biological father. Her mother remarried, and she was raised by Arley Call George and Elsie Marie Nott. Let’s add Ruth to that family.
We want to add Ruth to this family, so we click on the Add Child text.
Her record is already in the file, so we don’t want to create a new record for her. We click on the Search for Existing Child… button.
We find her record by clicking the Search for Individual… button
We highlight her name, and click the OK button.
Now she is in the family, but she is the oldest, not the youngest child, so we click on the bottom Order button. The Order button above it is used to place marriages in order.
I highlighted her name and started clicking the upward pointing triangle. Just two more clicks, and she will be the first child in the list. Then we will click the OK button.
Now that she is the first child, we will click the arrow button next to her name to make her the primary person.
Here we will examine her relationship to her new family.
Arley is Ruth’s Guardian, but Elsie is not. Elsie is still the Biological mother. The PAF file format has no way to store that information, so…
Lets examine this same relationship when it is stored in the AQ file format.
The AQ file format has the ability to store information which will not fit into the older, smaller, PAF file format. Both formats can be opened, read, written and saved by the Ancestral Quest program, but the AQ format gives users added capability, without losing anything except the ability to use the older, slower, less capable PAF program to open it.
Conversion is simple. Click on the File tab of the Menu bar and select Database Converter. In a few seconds Ancestral Quest will create a new file containing all the information in the old PAF file, and with the ability to store information which could not be stored in the old format. Give it a try. Work with the AQ file format for one week. The older, smaller, less capable PAF file is still in your folder where you left it, just in case you choose to go back. I have never looked back since I changed. You probably won’t either.
Suggestions/Questions about AQ Will Do or Subjects discussed here? Leave a Comment Below. I would like to hear from you!
…and how to manipulate them
Here is a typical Name List. Notice the upward pointing triangle in the red box. The triangle indicates a sorted field. This one is attached to the Name field. We can tell that the field is sorted into ascending order because the triangle points up. Descending sorts point down. Here I have clicked on the Adjust Columns and Sorting button. This button brings up the Name List View Column Options screen. It is divided into two halves. The top half is labeled Select the Fields you wish to view. The bottom half is labeled Select the Sort Order for the information.
The top half of the screen is divided into four columns. The left window, labeled Available Fields, shows an expandable tree containing all of the fields stored in the AQ database. Clicking on any box with a + inside will show a list of the fields and subcategories contained in that category. Clicking on a – will hide the items listed within that category. To select an item that you want to view, first find it in the list, then highlight it by clicking on it.
In the second column there are two buttons. One contains a > and the other contains a <. The > button is used to move the selected Available Field into the Shown Fields box. The selected field will be placed below whichever item in the Shown Fields box is highlighted, so chose the position before adding the field to the box.
The item at the top of the list appears on the left of the Name List screen. As you look down the list, each item you see is placed to the right of the previous item on the screen. The order of the list can be changed by highlighting the desired item, and moving it up or down by clicking on the upward or downward pointing triangle on the left.
Any field except RIN can be removed from the Shown Fields box. Just highlight the unwanted item and remove it by clicking the < button.
The bottom half of the screen is divided into four columns. The right window is labeled Available Fields. It works in the same was as the Available Fields box in the top half of the screen.
The next column contains the > and < buttons, and they work just like the buttons above them.
The third column contains the Sort Fields box and the Sort Order radio buttons. The Sort Fields box can contain one, two or three fields. From top to bottom, they are in Major, Intermediate, Minor order. This means that when you look at the sorted list, the item which is the Major order field will be sorted first. If the Major field is Sex, then the list will be divided into one, two or three groups. If all the names in your database were males, there would be one block of names. It wouldn’t be obvious by looking at the list that it had been sorted. If your file contained both males and females, then the list would appear in two blocks. One block would contain males and one would contain females. If you had records of people for whom you were unable to determine the gender, there would be a third block containing those records.
The order of those blocks is determined by the radio buttons. If you select Ascending, Females will be first, Males second, and Unknown last. Descending would show Unknown first, Males second, and Females last.
Go back and look at the first two illustrations. In the first illustration there is an upward pointing triangle in the Name column, so the list is sorted by Name, alphabetically from A to Z. In the second illustration, the Ascending radio button is selected, and there is an A before the field name in the Sort Fields box. Now I will change the sort order.
The Intermediate sort order is Birth/Mar/Death Date, so within each place, the records will be sorted into date order. The dates are being sorted into Ascending order, so within each place, the records will be listed from earliest to most recent.
The Minor sort field is Name, so within each date, the names will be listed alphabetically. the Ascending order was chosen, so the sort will be from A to Z. At first glance, it looks like there is some type of error with the sort. The places were supposed to be in alphabetical order, so Fownhope shouldn’t come before Cheddleton. Here is what happened. In Tools -> Preferences -> Formats there is a check box item called Sort Places Small to Large on Name List View. This box has not been checked, so places are sorted by Country, State or Province, County, City. This is why it is important to store ONLY place name information in place fields. Our sort is in England, Ireland, United States order. If I had the name of a cemetery in the City position of the place field, everything would have been out of order. Since I have only three place names for my places in England and Ireland, I leave the State or Province portion blank by inserting an extra comma as a place holder in the name.
Now let’s put a check in the Sort Places Small to Large on Name List View box and see how that changes everything. Now the places are sorted by city, then county, then state or province, and lastly by country.
Just one more thing. Notice that the column headers Place, Date and Name all have upward pointing triangles. those fields are sorted into ascending order. Notice also that the triangle for Place is larger than the one for Date, and the one for Date is larger than the one for Name. This is how you can visually identify the Major (largest) through Minor (Smallest) sort order.
Ancestral Quest makes backups as a precaution, to protect us from hardware failure, and also as a way to make files smaller, for attaching to emails. It can backup both the PAF file format, and the Ancestral Quest format. We will discuss only the .aqz backups.
Users sometimes overlook the fact that they have some control over how the backup file will be named when it is placed on the backup device. The ability to control the name, also gives us the ability to change our backup file strategy.
Let me explain what that means. Suppose I receive a GEDCOM from a relative. I restore my existing file, and I foolishly import the GEDCOM into my file. I merge some of the records from the import with records of the same individuals in my file. I add a few new pieces of information, and I make a backup when I finish working in AQ for the day.
On the next five days, I work on my file, and faithfully make a backup after each session.
That is when I discover that most of the GEDCOM file I imported contained records of the family of the spouse of my relative; thousands of them. Whether or not I can recover by restoring a backup will probably depend upon how I name my backup files.
How can that be? Let me show you, with a different example, how my backup directory would look under the following five different backup naming conventions.
1. Name Only
2. Name + Date in dd Mmm yyyy format
3. Name + Date in dd Mmm yyyy, + Time in hh-mm format
4. Name + Date in yyyy-mm-dd format
5. Name + Date in yyyy-mm-dd, + Time in hh-mm format.
Now let us assume that I have a file that I have been working in occasionally. This year and last, I made backups on eight days. I will show the backup directories as they would appear for each of the five backup file naming strategies.
These are the dates of the backups:
10 January, 2013, at 6:15 pm, 10 April, 2013, at 4:13 pm, 10 April, 2013, at 4:23 pm, 15 April, 2013 at 7:16 pm,10 January, 2014, at 10:49 am, 10 April 2014, at 2:07 pm, 10 April, 2014 at 2:37 pm and 14 April, 2014 at 6:38 pm.
Under strategy 1, I have only the last backup that I made. It took the place of a prior backup, because all backups have the same name. Under this strategy, I must catch all problems in my database immediately, if I want to correct them by restoring a backup.
Directory lists are sorted as strings of alphabetical characters. In this format, the day of the month gets sorted first, and all months get sorted within the day. The years get sorted within the month. That means that all backup files made on the 1st day of any month in any year will be sorted together, and the months will be sorted within the day. April will sort before August, then December, then February then January July, June, March, May, November, October and lastly, September.
The 2nd and 6th backups in this example were replaced by the 3rd and 7th backups respectively, because the 3rd backup had the same name as the 2nd, and the 7th had the same name as the 6th. There is no logical order in the list. You must search for the most recent backup.
Since the time is included in the name of the backup, all of the backups are in the directory, but their order is confusing at best.
These are in order, but because the 2nd and 6th backups were each followed by another backup on the same day, the file names were the same, and the first backup from each day was replaced by the second.
Now all of the backups are in the directory, and they are in order. Notice that the file names are sorted in ascending order. If you click the direction indicator, you can change it to a descending order sort.
Now you don’t have to search for the most recent backup. It is on the top of the list, and the backups become progressively older as you go down the list.
The best part about all this is that you can tell Ancestral Quest to build the backup file name for you. Here’s how.
On the Menu bar, select Tools. From the Tools menu select Preferences.
Click the Database tab. In the Backup (.aqz) File Names box, put a check in both boxes, and click the 2000-06-25 radio button. Click OK and AQ will form backup file names so that they fall into chronological order.
In the previous article on Descendant Research, we discussed how to download the descendants of an ancestor from the FamilySearch Family Tree. There is much information available in Family Tree, however, the research on that information is sometimes questionable. I recommend that you not import this information directly into a good file. How then should someone handle this information?
I recommend that you create a separate file for the descendants of ancestors. There you can examine it and determine what you do and do not want to incorporate into your file.
This is a six generation pedigree chart. It shows standard Color Coding, but with the males in the 6th generation highlighted.
To accommodate various screen resolutions and sizes, only five generations are shown on the Pedigree view of Ancestral Quest. Standard procedure for descendant research as taught at the Ogden FamilySearch Library is to begin with 3rd great grandfathers. They are the sixth generation when you are the principle person in the Pedigree view. These are the couples just off screen to the right. To see your paternal 3rd great grandparents, click on any of the top eight arrow buttons to the right of the last generation in view.
They are the ones outlined here in the red rectangle. To see your maternal 3rd great grandparents, click on the Home icon,
then click on any of the bottom eight arrow buttons to the right of the last generation in view.
This will show your maternal 3rd great grandparents.
Here is the procedure I recommend. Start with your paternal 3rd great grandparents.
Write the RIN numbers of the eight males on a list. If one of the males is missing, but his wife is present, write her RIN. If both are missing, drop down one generation, toward you, and write the RIN for that person.
Another way to think about this is to start with the principle person, who at this point is your father, and working up the ancestral tree generation by generation, write the RIN for any name you find who has No parents on the pedigree chart. On the sixth generation, write the RIN for only one person from each couple.
When this is completed, click on the Home icon, then move to your maternal 3rd great grandparents.
Repeat the process of writing RIN numbers to the list for these ancestors.
When you are finished, you know everyone who will be on the GEDCOM you are about to create, so click on the Export icon.
We only want the people whose RIN we have written, so click the Partial radio button, then click the Select button.
On this screen, you will select the people whose RIN you have written.
1. Be sure that the Sort order for this screen is RIN, not Alpha.
2. Be certain that the Selections by Relationship box is set to Individual.
3. Enter a RIN from your list.
4. Click the Select button.
Repeat steps 3 and 4 until you have entered all the RIN numbers on your list.
5. Click the OK button.
If you were able to select one from each couple in the sixth generation, you will have selected 16 Individuals. If not, the number may be lower. Click the Export button.
Select the folder where you want to store the file, and give the GEDCOM file the name you want, then click the Export button. The file will be stored where you indicated.
Close the current file, then…
tell Ancestral Quest to create the new file.
Show Ancestral Quest the folder where you want to store the new temporary file, choose the file name and click on the Create button. AQ will create the file with no records. Your next task is to import the GEDCOM file.
Click on the Import icon.
Be sure that you are looking in the right folder. Highlight the name of the GEDCOM file containing your 3rd great grandparents. Click on the Open button.
Select your choices for how to import the file, and click the OK button. When AQ finishes importing the file…
it will look something like this. Make a note of how many records are in the file. Now, refer back to the previous article on Descendant Research, and follow that procedure on each of these records. When you are finished, it is probably a good idea to check this file for possible duplicates. You are now ready to examine what you have returned from Family Tree. What you like, you can put into your real file.
Just what is a GUID?
UUID is an acronym for Universally Unique IDentifier. The term is further defined in a document published by a group called Network Working Group. They defined it this way:
“A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation’s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.” (Network Working Group)
The document in the link above contains a Copyright header file and six files of C code, for those of you who dabble in that language. (The Copyright is actually a Copyleft.)
In the genealogy world a UUID is usually referred to as a GUID, Globally Unique IDentifier. The biggest difference between the UUID in the specs and the one used by Ancestral Quest, Legacy and Roots Magic is the four hexadecimal character checksum added onto the end.
These three programs, and some others, create a GUID for every individual record which they create.
So just what does “Globally Unique” mean?
If every person in the world who was living at the beginning of the year 2014 were to create 600 million individual records using one of these programs, there is only a 50% probability of any one of those records having a duplicate GUID among the others. To see the generation of GUIDs, click on this LINK.
These programs each have their own file formats, and they are not interchangeable. None of the programs can open a file created by one of the others. Information can, however, be passed among users of different programs. This is done by exporting and importing that information through a GEDCOM file. When we look at a line in a GEDCOM file we see distinct fields. The first field is a number which shows grouping of information within the file. A zero denotes the start of a new record. Numbers higher than zero are somewhat like levels of indentation. The second field in the line is the GEDCOM Tag. This identifies what type of information is on this line and immediately following lines with higher level numbers. There are Standard Tags, but the _UID Tag is considered proprietary. Even though it is considered proprietary, it is used by several software vendors, including Ancestral Quest, Legacy and Roots Magic. To demonstrate the use of the _UID Tag in these three products, I created a record for John Jones using each product. I next exported this one record from each program with GEDCOM.
This is the GEDCOM from the Ancestral Quest file.
This is the GEDCOM produced by Legacy. Note that it is not exactly like the one from Ancestral Quest.
This GEDCOM was produced by Roots Magic. It is very unlike the other two. The zero level TRLR Tag is on line 728 of the file.
I started the Roots Magic program, opened its file and imported the GEDCOM records from Ancestral Quest and Legacy. I then merged these two new records into the original Roots Magic version of John Jones. I created another GEDCOM file showing the resulting merged record.
This is the GEDCOM file showing the new record.
I started Legacy, opened its file, and imported the GEDCOM records from Ancestral Quest and Roots Magic. I merged the two new records into the original John Jones record, and made a new GEDCOM file to show the results.
This is the resulting GEDCOM file from Legacy.
I opened the AQ file in Ancestral Quest, and imported the Legacy and Roots Magic GEDCOM files. I merged the two new records into the original John Jones record, and created a new GEDCOM file to show the results.
This is that GEDCOM file. Note that only Ancestral Quest maintained the integrity of the process by keeping all three _UID Tags.
Just suppose that I created a file containing a record for Jack Smith. Next suppose that I sent this file as a GEDCOM to a relative. Now suppose that my relative merged my file into his, which also contains a record of Jack Smith, which he merges into his file. If he is using Ancestral Quest, his version will contain both his own GUID and also my GUID. If he sends that file back to me, I can find the matching record using an Auto Merge on GUID. If my relative used one of the other products, my version of the GUID would be filtered out when he did his merge. When he returned the file to me, my Auto Merge on GUID would not find the match. Oops!
Merge – Simple
By Merge – Simple, I don’t mean to imply that it is simple to merge. What I mean is that there is more than one way to do this, and the methods vary in complexity. This method is less complex than some others.
I sometimes tell my wife that Delete is almost always a problem. Delete is almost never the solution.
When we find two records in a file representing the same person, it may seem that deleting one of the records would be an acceptable solution. This would be true if, and only if they contained the exact same information, AND the record to be deleted has no relationships with other records in the file. (Child, Spouse, Parent)
For this example I created a record for Jonny Van Hook III. Since the Dutch recognize the Van part of the Surname as a Prefix, and because Ancestral Quest does not store a separate Surname Prefix, I mistakenly store the Van in the Name Prefix field. I also use the Nickname, Johnny, instead of his real name, John. I mistakenly omit the county from the Birth Place.
I export the record via GEDCOM, then I import it three times. I now have four identical records. I correct the first record, so that I will have fields to contrast during the Merge process. I create parents for RIN number 2. I create a spouse for RIN number 3, and I create a son for RIN number 4.
This is the Name List. The RIN 2, RIN 3 and RIN 4 records are identical except for the RIN and their relationships. The record with RIN number 1 is highlighted. The record with RIN number 2 is not needed, so we will merge it into the first record. To do this we click on the Merge icon.
The highlighted record does not get listed in the Merge Individuals screen. To get it there we must click the Left Search button. The Left Search button selects the Primary Individual.
Record 1 is selected, so we click the OK button.
Next we select the record with RIN number 2. To do this we first click the Right Search button. The Right Search button selects the Duplicate Individual.
We enter 2 as the RIN and click the OK button.
We correct the errors in the Name fields by clicking on the squares which are pointed at by the red arrows. We click each until it becomes a blank square. If we had wanted any of those name pieces to go into Notes, we would have stopped clicking when the square was filled with the letter N on a green background. Name pieces cannot go into Other Events, however other fields like dates and places can. If we wanted such a field to go into Other Events, we could stop clicking when the square was filled with a downward pointing arrow.
Ancestral Quest recognizes that a Place Name with all four parts is better than a partial Place Name, so it defaults to selecting the correct one, with nothing in Notes or Other Events.
Note that the red Duplicate record had parents linked to it. These will be linked to the Result record after the merge. We click on the Merge button.
RIN number 2 has been merged into RIN number 1, and RIN number 1 has the parents attached. We are now ready to merge RIN number 1 and RIN number 3. We click on the Right Search button, then enter 3 in the RIN number field and click the OK button.
Here we follow the same procedure. We eliminate what we don’t want and take the rest. Note that the parents are attached to RIN number 1 and the spouse is attached to RIN number 3. After the Merge, RIN 1 will have parents and a spouse. We click the Merge Button.
RIN 3 has been merged into RIN 1. Both the parents and the spouse are attached to RIN 1. Next we want to merge RIN 4 into RIN 1, so we use the same procedure. We click on the Right Search button, enter 4 in the RIN field, and click the OK button.
We repeat the same procedure. We eliminate what we don’t want, and keep the rest. Note that RIN 1 has parents and spouse attached, and RIN 4 has a son attached. When we click on the Merge button, we will eliminate RIN 4 and RIN 1 will acquire the son. We click on the Merge button.
RIN 4 is merged into RIN 1, which now has parents, a spouse, and a son. We click the Close button.
This is the new Name List view with all duplicate records properly merged. Or are they? NO!
During the last merge, RIN 1 already had a marriage with RIN 7. RIN 8 was a child in a marriage with RIN 4 and an UNKNOWN wife. When RINs 1 and 4 merged, RIN 1 now had two marriages. To solve this problem, move the son to the principle position by clicking on the arrow left of his name.
Click on his Other Parents/Rels button.
The first marriage was with the parents of John Van Hook. The second was with John and his spouse, Sarah James. The third marriage, shown above is between John and an UNKNOWN spouse. We want the son to be a child in a marriage with John and Sarah James, so we will add an existing set of parents to RIN 8. That set of parents will be John and Sarah, in MRIN 2. We click on the New button.
We want to go find that marriage. We click on the Search for Existing Parents button.
If we didn’t know the MRIN, we could have used the Search for Marriage button, but we will enter 2 in the MRIN field and click the OK button.
This is the marriage we want, so we click the OK button.
Now that the son is safely into a real marriage, we will click OK to get out of the Parents screen.
The son is now a child in two marriages. To fix this, we put John in the Principle position, and select his UNKNOWN wife. We click on their Marriage button.
Since we want neither John nor his son to be in this relationship with a non existent UNKNOWN woman, we click on the Delete button. We assure AQ that it is OK to delete the marriage, and…
the Merge process is completed.
Descendant research is the practice of selecting one or more distant relatives, and researching their descendants, instead of their ancestors.
In ancestor research, the focus sometimes shifts to finding more and more generations. In descendant research, the focus is always on “how wide” instead of “how tall.” Descendant research is a lot like harvesting an apple orchard. It is easiest to reach the low hanging fruit.
The current version of Ancestral Quest (14.00.19, Both Free & Full versions) includes the ability to do descendant research using the FamilySearch Family Tree. It is tucked away in the Menu Bar under FamilySearch | Import Family Lines. Be aware that there is a lot of information in the Family Tree which was researched poorly. Before doing large imports from this source, I recommend that you create a temporary file to hold the information, so that you can evaluate it before actually placing it in a good file. To learn how to build this file, and systematically “harvest” your Family Tree, link to the next article on Descendant Research.
For this demonstration I have selected my 3rd great grandfather, and created a file with his as the only record.
This is the Import Ancestors from FamilySearch screen. It was named before descendant research was possible in Ancestral Quest. The first thing you will need to do on this screen is to click the Add Descendants to Person radio button. Since I started with my 3rd great grandfather, and his generation will not be included in the count of generations, I will come back down the descendant lines for 5 generations. This will reach down to my generation. Since all of my siblings are living, I can reasonably guess that most of the people in this final generation will also be living, so I un-click the check box to indicate this. Now I click the Import button.
Since some people will import into a good file, Ancestral Quest gives them one last chance to preserve the integrity of their file. We are using a temporary file, so we will not do the backup.
Ancestral Quest begins downloading records. If the account used to access the Family Tree was a non-member account, AQ will report how many individuals were downloaded, and the process will be completed.
If the account used was a member account, Ancestral Quest will access the temple records for the downloaded individuals. AQ will give a count of how many records were downloaded, and the process will be completed.