Free 8x10

I found the following stamped on the back of a photograph from the mid 1920s.

In 2014, in the era of digital photography, film processing “Kodak Finishing” is largely a thing of the past.  This makes me wonder how much Kodak Finishing one got for a dollar 90 years ago.  Also, how much would an 8x10 enlargement have cost without the special deal?

609 Pound Soldier

When I found the World War II Army Enlistment Record for Woodrow Grider, I was surprised to see his weight listed as 609.  Since these were US records, I’m assuming it’s pounds instead of kilograms -- 609 kilograms would be 1343 pounds!

Even at 86 inches (7 feet 2 inches), 609 pounds would be gigantic.  I seriously doubt that World War II US Army uniforms came in XXXXXXXXL.

It’s a Long Way from California to Columbia

There has been a lot of talk about the quality of the 1940 census index at ancestry.com.  In most cases, I am willing to make updates as they suggest and not worry about the obvious mistakes.  However, this one was just too outrageous not to mention.

I’m talking about Cecil P Bradshaw.  He was widowed and living with his brother in Bell County, Texas, in 1940.


The first inexcusable error was that his name was misspelled in the index as “Crcil”.  Anyone who is comfortable with English would have come up with “Cecil” rather than “Crcil”, unless it is simply a typo.  No problem.  I added the correct name to ancestry.com.

The second error was more egregious. 


The state of residence in 1935 was transcribed as “Columbia” rather than California.  Anyone familiar with United States geography at all would not have made this mistake.

And here’s where I have to complain.  Subscribers are not allowed to make updates to the 1935 residence information which means that I have no way of helping others with a corrected index entry. 

Recovering from a Family Tree Maker sync error [Tuesday’s Tip, Tech Tuesday]

I want to go on record that I absolutely love the fact that I can synchronize my family tree between ancestry.com and Family Tree Maker 2012.  It is easy to do, and it lets me work in Family Tree Maker most of the time, but view and share my tree online via ancestry.com.

There have been some growing pains, though, and sometimes the synchronization fails.  If the problem doesn’t correct itself over time, the general advice is to disconnect the tree in Family Tree Maker from the one in ancestry.com, and either re-download from ancestry.com, or re-upload from Family Tree Maker.  Either way is no fun.

Recently, I encountered one of these errors and am happy to report that I was able to resolve it without taking drastic measures.  When I looked at How do I troubleshoot my TreeSync feature for Family Tree Maker 2012? I found directions for gathering information that Tech Support would need to help with the problem.  I thought, “Maybe I can be my own Tech Support.”

First, I poked around inside the information, saw an error about “zipping”, and found directions to a particular temp folder that Family Tree Maker uses (…AppData\Local\Temp\FTM).  The folder had 13,695 files in it and was very slow to open.  That seemed like a problem.  Since it was a Temp folder, I deleted it.  (Ok, I didn’t actually delete it, but I did rename it.)  After that I tried the synchronization again and was disappointed when it still failed.

I poked around some more and found a different error. The second error seemed like it had something to do with Media.  I tried the synchronization again and clicked on the View Details button.  Part of it looked a little like this “Changes from Ancestry” screen portion.

I found Richard McDuff in my online tree and removed the picture that I had linked to from someone else’s tree.  I synchronized again, and it was successful!

Apparently media files are often the cause of synchronization issues.  That’s the first place I’ll look next time I have a problem.  Many people may not feel comfortable poking around in technical log files like I did, but some will.  I don’t recommend deleting things or changing them outside of Family Tree Maker, but reading those techie log files can’t do any harm.

It hurts to index this

While indexing a page in the 1940 census for Dawson County, Texas, I found the following 1935 residence information for Clara Owen.

The handwriting is perfectly readable:  Bartlesville – Choctaw – Oklahoma.

Unfortunately, it’s wrong.  I know that, and I don’t even know Clara Owen.  You see, I grew up in Bartlesville, Oklahoma, so I know that Bartlesville is not in Choctaw County.  It’s in Washington County.

The two counties are not even close to each other.


A part of me REALLY wants to index the county as Washington, but I won’t for a couple of reasons:

• It’s possible that the city is wrong instead of the county.
• The arbitrator would absolutely consider it an error.

Adventures in Indexing #4 – Texas A&M

My most recent page to index in the 1940 US Census is from College Station Texas, home of Texas A&M University.  This was a tedious page to index because there were no family groups to offer repeated information such as Surname. 

The page started with Manuel Salas, Partner, Male, White, Single, 27 years old, from San Antonio.

My first thought was that this was a page of students, maybe a men’s dorm.  I had to go back two pages to find the household number; when I did, I found the following notation:

Here begins the enumeration of the Texas A&M College dormitory for Mexican employees of the Dining Hall

That gave me some context, but still didn’t answer my curiosity about the term Partner in the Relationship field.  There were many people on the page listed as Partner.  I found my answer in the enumerator instructions:

If two or more persons who are not related by blood or marriage share a common dwelling unit as partners, write head for one and partner for the other or others.

One more interesting thing about this page.  Every one of the people in this section had a Hispanic surname, as you would guess from the description of “Mexican employees of the Dining Hall”.  However, every one of them was also listed as White rather than Hispanic, even the ones who were listed as born in Mexico.

Adventures in Indexing #3

I’ve been helping with the indexing of the 1940 US Census for 11 days now and have completed about 20 batches.  I decided it was time to check my arbitration results to see how accurate I was.

I was pleased to see that almost all of my batches were in the 98-100% accuracy range.  Well, there are so many fields to transcribe that 100% doesn’t really mean zero errors;  it just means that less than half a percent of the transcribed fields were judged to be in error.

However, there was one batch that was low at 91%.  I wondered why that one was so much lower than the others.  What did I find?  One error about 25 times.  “W” instead of “White” in the Race field. 

If you’ve been indexing, you know that the software is kind enough to auto-fill fields.  For instance, once you’ve typed “Texas” in the Place of Birth field one time, you can just type “T” and tab out of it on later rows and it will automatically fill in the rest of the word.  However, if you have entered more than one value that starts with “T” (Tennessee, for instance), it won’t auto-fill until you have typed enough letters for the system to know which one you want (Tex or Ten). 

As best as I can guess, on one line I must have typed a space after the W in the Race field, so it didn’t fill in the rest.  Then on subsequent lines, when I typed W it wasn’t unique.  When I tabbed to the next field, it didn’t auto-fill.  Unfortunately, I didn’t notice the mistake and it continued through the rest of the page.  Maybe I didn’t notice it because some of the other fields (Sex, Marital Status) are entered as only the starting letter.

What’s interesting to me is that the Quality Checker didn’t catch my mistakes.  I’d love to see an upgrade to the indexing software that would include the Race field in the Quality Checker!