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.
Suggestions/Questions about AQ Will Do or Subjects discussed here? Leave a Comment Below. I would like to hear from you!
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, Jonny, 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.
110 Year Rule
This Lesson is for Members of The Church of Jesus Christ of Latter-day Saints.
The 110 year rule tells us that as a courtesy to more closely related family members, we will not reserve ordinances for deceased individuals born more recently than 110 years ago, without the permission of those living relatives. This begs the question, “How do I find those older deceased individuals in my database?” This is relatively easy, once you know how. (Funny how it always works out that way.)
Start by opening your file. Since you are attempting to reserve ordinances, you will go to the FamilySearch tab, and select the Ordinance Reservation and Tracking System.
After entering your User Name and Password, click on the Sign In button. After successfully logging on, you will see the Ordinance Reservation and Tracking System menu.
Click on the Reserve Ordinances button.
This will bring up the Reserve Ordinances/Create Batches screen. Here you will want to begin selecting those older deceased ancestors, so click on the Add button.
On the Add Names to List screen, you will want to click on Add Selected Local Record(s).
On the Find Individual/Marriage screen, click on Search for Individual.
Be certain that the double arrows on the Advanced button are pointing in this << direction, or you will not be able to click on the Define button.
In the Possible Fields window on the left, highlight RIN, and click on the > button. This will “push” the RIN field into the Current Filter on the right.
When the RIN Field Filter first appears on the screen, it will be showing a range of numbers beginning with the lowest numbered RIN in your file and ending with the highest numbered RIN. This range will be used to limit the number of records which will be selected from your file. You will need to experiment with the values for both the beginning and ending numbers in this range, because there other factors which will be added to the filter which will also lower the number of records to be selected. Lets start with the range of RIN numbers from 3001 to 3100.
Enter these values into the From and To fields, and click OK. This will exclude all records with a RIN lower than 3001, and all records with a RIN higher than 3100. Each condition we place into the Current Filter will potentially exclude more records.
We want to “push” other conditions into the filter, so we will click on the AND button. Now we are ready to check on the age of the individual.
In the left window, highlight Birth Date and click on the > button to “push” it into the Current Filter.
As the date gets smaller, it moves further back in time, so we want a date less than today’s date minus 110 years. In this example, today’s date is assumed to be 22 Apr 2014, so we calculate that 110 years earlier the date would have been 22 Apr 1904. We want only Birth Dates that are less than that date.
We enter 22 Apr 1904 into the Date field and click on OK. This will exclude everyone born on or after 22 Apr 1904. We now want to exclude people for whom we do not yet have enough information to do ordinance work, and people for whom the ordinance work is already done, so we need to add more conditions to our filter.
We click on the AND button. There are now three groups of records which we do not want to exclude. The first group is people who are eligible for personal ordinances (Baptism/Endowment). The second group is people who are eligible to be sealed to parents. The third group is people who are eligible to be sealed to spouse and children. We will treat these three groups as one group, so we need to show that they are a group. We begin a group by clicking on the ( button.
To find the three groups we scroll to the very bottom of the left window.
The first group we find is Qualified for Baptism/Endowment. We highlight that group and click the > button to “push” it into the Current Filter.
We are not looking for people who do not yet qualify. We are looking for those who do, so we select the Is radio button, and click on the OK button.
To be on our list, a person does not need to qualify for all types of ordinances. They can qualify for one type OR two types OR all three types.
We click on the OR button.
We highlight the next group, Qualified for Seal to Parents. We click the > button to “push” it into the Current Filter, and we accept the Is radio button.
We click on the OR button.
Highlight the last group, Qualified for Seal to Spouse, and click the > button to “push” it into the Current Filter. Click OK to accept the Is radio button.
To close the group and the filter, we click on the ) button. Now our filter is completed.
After all that work, we don’t want to lose what we have done, so we click the Save button, and select a name for our filter.
Now our filter is saved. We can use it as it is for now, and later, we can highlight the RIN range, and modify it to get a different group of names. On a different day, we can retrieve the filter, and change the Birth Date so that we aren’t skipping anyone unnecessarily.
At this point, click OK to exit the filter then click OK to exit the selection process. The selected records will appear on the Reserve Ordinances/Create Batches screen, and you can proceed with your ordinance reservation. At some time after you finish, you can repeat the procedure, but this time when you click on Define, you will next click on Retrieve, and change the range of RIN numbers, and if necessary, the date.