What's Actually Wrong with Ancestry.com: Hundreds of Incorrect Hints

Really, ACOM? Is Laudel, Vest-Agder, Norway
really in Denmark?

Excuse me while I rant for a moment about how once again ACOM's nonsensical system makes for inefficient genealogy work.

I just got literally hundreds of hints for my Norwegian branch and so far not a single one is accurate. The hints system seems to go off of name and dates only, not locations. I get that people move around and shouldn't be defined by one location... but when I have a birth/baptism location for someone in my tree, why is it giving me hints for births/baptisms in a completely different county or sometimes even nation?! The system doesn't understand how repetitive Scandinavian names are, because they used patronymic names, there will be thousands of Lars Gundersens, for example, and dozens of them born in or around 1833. That doesn't mean someone who was clearly born in Norway matches a birth/baptism record from Denmark! Why are locations not included in the criteria for hints?

It would be fair enough if I was getting a Denmark hint for a marriage when the individual was born in Norway - it's not impossible an individual moved from Norway to Denmark in between their birth and marriage. It also wouldn't be unreasonable if I had no location entered for a birth. But I'm talking about Denmark birth/baptism records popping up for people who have a birth/baptism location as Norway. Likewise, a lot of Norway records are popping up too but they are all in the wrong county!

If it were just a handful of hints, it would not be a big deal. But I now have to go through literally hundreds of hints and make sure they are truly bogus before I delete them. If I could just hit "ignore" it might not be so bad but on half the Norway hints, the location isn't listed until you view the record, which means I can't just look at the hint overview and click ignore, I have to open up the record, compare the locations, then hit ignore.

Thanks for making a whole bunch of tedious busy work for me, ACOM!

What's Actually Wrong With Ancestry.com: Adding Non-Indexed Images

I often come to the defense of Ancestry.com because frankly, they get accused of a lot of things which simply aren't true. When this happens, I get accused of believing Ancestry.com can do no wrong. But this is far from the truth, I have a lot of criticism for Ancestry.com and since I have already taken my complaints to them via their feedback and customer support many times and nothing ever gets resolved, I am instead going to use my blog as my outlet. So I certainly will not deny that Ancestry.com customer service is terrible.

Otherwise, some of my complaints may seem minor, and indeed they are not worth cancelling my subscription over. The fact of the matter remains that Ancestry.com has the biggest genealogy record database on the internet and therefore is a valuable resource. But when you're trying to do time consuming work on your tree, it's the little things like this which can really inhibit your work flow and when you're paying about $300 a year for a service, I think it's fair to expect basic problems like this to get resolved quickly.

Note the blank events the system creates instead of
attaching the citation to existing events. I leave them
blank so I know which ones to delete but the system
gives you the option to fill them in during attachment.

Today, I'm going to talk about the feature that allows you to add a non-indexed image to your tree. While this feature in itself was a great idea, it's got some major bugs in it that make it almost not even worth using.

For starters, it won't allow you to attach the image to an existing fact (shown right) and instead creates a new one. This means if you're trying to add it as a citation for an existing birth event, for example, it will create a new preferred fact for the birth and your original fact will be made the alternate fact. Annoying, right? You then have to edit the citation to switch it over to the correct, original birth fact but this is not easy since, for some reason, the citation did not save the title of the source! If it's the first time you're saving this source, you have to create a new source with the title but at least once you've added it, from then on you can just select it from the drop down menu when adding this source again in the future. Of course, in order to save the citation you also have to enter something into the "Detail" field. This is a problem with many sources, even those indexed - if they do not have a "detail" entered by Ancestry.com's system, you have to enter it yourself when editing the citation.

Once you've finally edited the citation so it has a title, detail, and is attached to the correct facts, you then have to delete the new facts that the system incorrectly created. Because it didn't just create a new birth fact, it also created an alternate name fact.

There are three Tobias Leechs in my tree but two don't have
birth or death dates yet, how do I tell them apart? Suffix of
I, II, or III don't appear.

If all this weren't enough of a pain in the ass, pray you never have to attach the image to an individual who shares a name with someone else in your tree unless you already have a birth or death date entered for at least one of them. The screenshot to the left should show how, in the drop down list of people in your tree to select from, there is no way to distinguish two people with the same name unless they have a birth and death date. Despite the fact that these individuals have been entered with a "suffix" title like Sr. or Jr. or I, II, and III, these suffixes do not appear on the list, making them rather useless in these circumstances. Even when there is a birth or death date entered, be sure to remember which one it is you're attaching it to. I believe this is a problem when attaching any record to an individual selected from the drop down list, even an indexed record. Allowing the suffix to appear on the drop down list should be a quick, simple fix in the system yet the problem has remained for as long as I've been a member since 2008.

So, if you're going to criticize Ancestry.com, here is something that is honestly wrong with it.

Why Probate Records Are So Important.

Today, I made a remarkable discovery. Well, it's remarkable to me. It was accomplished almost entirely with the Pennsylvania Probate Records found at FamilySearch.org and is a testament to how important these records are and how much you can learn from them if you take the time to find and study them. It also proves research before the almighty 1850 US Census can be done.

Ann Sutch Will 1827 mentioning brother Richard
Shoemaker.

I had been searching for the parents of my ancestor, Ann Shoemaker, for a while. All I knew of Ann was that she married Daniel Sutch, had 4 daughters, and then died in 1827 in Gwynedd, Montgomery County, Pennsylvania. I did not even know when she was born but I approximated it around 1760. But I did also know she had a brother named Richard. I discovered this from her will in the Montgomery County Probate Records, proved in 1827, which specifically named her "brother Richard Shoemaker" as executor of her will (shown above right). This not only gave me her maiden name but also a brother's name to research. It was difficult though, because all I knew of Richard was that he was probably alive (and an adult) in 1827, and likely lived in Montgomery County. But Shoemaker was a common name in that area and Richard was not uncommon either. Without knowing anything else about him, how could I confirm records to be the Richard I was looking for?

Well, in the Proceedings Index for Ann (Shoemaker) Sutch, there were some listings for Orphan Court Dockets. These are often records that have something to do with the will of a deceased person after it was proved. There were two dated 1838 which turned out to be a petition and answer for the replacement of trustee Richard Shoemaker, deceased, with someone else. The petitioners were E. Jones and Job Roberts (I promise this will be important later on). This suggested that Richard Shoemaker, brother of Ann (Shoemaker) Sutch, died sometime in or soon before 1838. So I went looking for a Richard Shoemaker who may have had probate records dated around 1838. There was only one in Montgomery County who fit with this and although there was no will listed, there was an Admin Bond date for Aug 5, 1837 in Horsham and the Admins listed were Job Roberts and Evan Jones. So I knew I had the correct Richard Shoemaker because Jones and Roberts were listed in the Orphan's Court record for Ann Sutch, sister of Richard Shoemaker.

But that's not all. Once I entered Richard's death year as about 1837 in Horsham, a Quaker record on Ancestry.com popped up for a Richard Shoemaker who died July 10, 1837 in Montgomery County (subscription required to view this record). I looked at it and although it didn't say he died in Horsham (there was no death location at all), it did say his father was Ezekiel Shoemaker who had died 1816 in Horsham. I already had a hunch this was my Richard Shoemaker because in the Estate/Proceeding Indices, there was only one Richard Shoemaker who died in or around 1837 in Montgomery County (and if he died in July, a probate record in August made perfect sense). But just in case there was another one who perhaps didn't have any probate listings at all, I decided to research Ezekiel.

Firstly, I noticed on the Proceedings Index right above my Richard Shoemaker there was another entry for a Richard Shoemaker who died around 1790 in Horsham and his executor was named Ezekiel Shoemaker. I looked at his will first and sure enough, Ezekiel was his son. Best of all, two of his daughters married into the Roberts family, which linked this elder Richard and son Ezekiel back to my Richard, because if you recall Job Roberts was listed in my Richard's probate records (who would have been this elder Richard's grandson). Granted, Roberts is a common name too but there's starting to be too many coincidences to ignore. Additionally, according to other family trees, my Richard also married a Roberts.

Ezekiel Shoemaker 1816 Will naming his daughter,
Ann "Such" (Sutch).

I looked up Ezekiel in the probate records and fortunately, he had a will and sure enough, in his will he names "my daughter Ann Such" (shown left). So not only do I now have proof that Ann was the daughter of Ezekiel, I also already have Ezekiel's father's name as Richard, and Ezekiel's siblings names as mentioned in Richard's will! A wealth of information, with the exception of one record, came entirely from these probate records.

To top everything else off, I then found a Quaker death record for Ann Sutch who died 1827 naming her father as Ezekiel Shoemaker of Horsham (subscription required to view this record). These must be new records added to Ancestry.com since I'm sure I scourged the internet looking for another death record for Ann once I found her will and knew she died in or before 1827. My search would have been a hell of a lot easier if I had just found this record first! Regardless, I still would have gone in search of Ezekiel's will to find out more about their family (like his wife's name) so the point still stands that probate records are important.

For some reason, there is a secondary record with no indication of the source or repository attached to some Ancestry.com member trees that claims Ezekiel's daughter Ann "died young". I hope I have been able to conclusively prove that this is not true with all these primary records I've mentioned and provided links to. Family trees put Ann's birth year as 1764, not far off the estimated birth I made around 1760, so if this is true she would have been 63 years old when she died in 1827. She married Daniel Sutch and had four daughters named Jane (b. abt. 1788, m. Charles Gilbert), Sarah (b. abt. 1791, m. William Davis), Ann (b. abt. 1792, m. Homer Dubree), and Hannah (b. abt. 1805, m. Joseph Amber). Some information on their family can be found in the Ambler Gazette.

So don't overlook probate records as an important method for finding that elusive previous generation. It may take a lot of digging and it may not always lead back to what you're looking for but you will likely discover something you didn't know before.