|Transcribing Parish Registers
|A database stores the information in what is known as fields
- one field for each item of data. A collection of fields make up the information
for one record, that is, all of the information about the one
person or event (e.g. a baptism). A collection of records makes up the whole
So what separate items of information (fields) do we need for an event such as a baptism? Furthermore, what information is available in a baptism register? The answer to the second question governs the answer to the first. Unfortunately, different baptism registers during different periods of time differ in their format and the amount of information they contain. In early parish registers we encounter a simple written statement such as Francis son of John Neep and Mary his wife was baptised 17 May 1779. In later parish registers, we find a pre-printed page with columns of information, including entry number, When Baptised (and often with the date of birth entered too), Childs Christian name, Parents names (Christian & Surname), Abode, Quality, Trade or Profession, and a final column By whom the ceremony was performed. Essentially, the later registers contain the most information, and so these must be the ones on which our standard is based. Sometimes of course, earlier registers do give more information, and even the later ones have additional information written in the margins on occasion. We need fields (items of information) in the database to cater for all of these, and we need to establish a standard way that the information is entered.
An example of a transcript of a parish baptism register, showing the fields (items of information) as columns, just as the data was entered. Note the use of the Notes column for additional information such as margin notes, etc. (Part of the baptism register for Parkend, Gloucestershire).
(The last one shows the method of recording a baptism where the father is
Parish (not shown in the example above)
My databases used to be without this field. That doesn't present a problem. But! If we later need to merge two databases to make searches easier, then it is an essential item. I would thoroughly recommend using it! The down-side is that the parish name needs to be entered for each line, but in practice what I do is type in an abbreviation, e.g. "pa" for "Parkend", and then later do a search and replace on that field, finding "pa" and replacing it with "Parkend"
There is no problem in having several parishes in one database. Even with several hundred thousand records, searches, filters and queries still only take a second or so. What I would perhaps do though, is have one database file for each county, or local area. It is much easier to search all parishes for children of a couple than one parish at a time!
No (The register entry number)
Pre-printed in later style registers, none in early registers. If transcribing an early register, then simply leave this empty. Note, as in the example above, that I use a four digit number, as some pre-printed registers for larger parishes go above 1000. I learned that one from experience, when sorting by entry number. Without the leading 0's the sort order is something like:
Format: dd mon yyyy/y e.g. 20 Jan 1834 or 20 Jan 1701/2
The birth date is usually not shown in early parish registers, so simply leave this field blank.
Why have this data format? The answer is that although it does not match the American format, it is unambiguous. (There could otherwise be a confusion between 12/1/1848 and 1/12/1848). It also allows us to enter a date before March 26th as the real year before the calendar changed in 1752. (Before 1752, the year number changed on March 26th).
Computer databases have a data type as text or date format. Unfortunately date data format is of no use for us as genealogists, because it doesnt like dates such as 23 Jan 1711/2, and some even get muddled up with older years such as 1798 or 1898, whilst being quite happy with 1998. So my recommendation is to stick with the data type as simple text. Sure, it can no longer be sorted by date, but we have a way around that problem later. If no birth date is given, then leave that item (field) blank.
Again, in the date format as above.
This is an extra item of information which we can add into the database, so that we can sort entries into date order later if need be. We cant rely on the vicar entering every baptism in chronological order. Quite often we see examples where one or more baptisms have been added at a later date. In final prints of course, the sortdata column is omitted. When we start getting clever with the use of filters and queries in a database, it is possible to have it list all the children of several couples with the same surname - in date order by family - if we use a "sort date" field.
The format I use for sortdate is yyyy mm dd, e.g. 1824 02 27 for 27th February 1824. (Again entered as a text data type). This gets over our problem of being able to sort entries into actual date order. We simply click on the sortdate column and then use the database command to sort it. It works perfectly.
This is simply the Christian name of the child. Occasionally when entering data, we encounter someone with several names, such as Francis William Jonathan. There is no harm in recording them all in this field, but it can present a problem when the transcript is finally printed. (Yes - I do like good old fashined paper for archiving information!). If we enter the full name, then it overflows the column in the final print, or some information is missed on the print. So what I do is use an abbreviation such as Francis Wm. J., and then make a note of the other names in the notes column at the right.
Why bother entering the sex? Surely it is self evident from the Christian name? Unfortunately this is not always the case, especially with an unusual name. In addition, some names have changed in their usage, for example Julian used to be a female name, whereas nowadays we use it as a male name. I prefer the use of son or dau rather than simply M or F, as it preserves the way that the original registers were written, and it looks better in printed reports.
Used for the fathers Christian name. If the original register does not state it, then this field is left blank. If however, the baptism is of an illegitimate child where the fathers name is not stated, then I use a dash -. (We cannot always assume that if the fathers name is not stated the child is illegitimate, for example, the father may have died).
Used for the mothers Christian name. The advantage in using separate fields for the fathers and mothers Christian names is that it is possible for a query to be made such as show me all the SMITHs, where the father is John and the mother is Mary, or even better, to sort the SMITHs by father and then by mother and also in date order. Presto! Family groups!
Father Surname (abbreviated to Fath surn)
Generally speaking, most registers only show the fathers surname. I always use upper case letters for real surnames. This avoids confusion where a surname is used as a Christian name, for example, one of my ancestors was William Watkins NEEP. I never use all upper case, or all lower case, as in the example quoted WILLIAM WATKINS NEEP or William Watkins Neep may be totally misinterpreted as being a double or hyphenated surname!
Mother Surname (abbreviated to Moth surn)
Usually, this is used where only the mothers name is stated in the register. However, there are exceptions. In some counties, for example Norfolk, it is not at all uncommon for the register to show the mothers maiden name. I have even seen examples where the mothers surname is entered as Johnson, formerly Jones. Fortunately, the meaning is always the same. Her surname before marrying was Johnson (ie. her previous married name), and her maiden name was Jones. What I always do is enter her previous name Johnson in the Mothers surname field, and then in the Notes column, enter formerly Jones. Again, I do not assume that if only a mothers surname is entered that the child was illegitimate. If the register entry states illegitimate, or her occupation as single woman, then I make a note illegitimate in the Notes column.
In later registers, (1813 onwards) and sometimes earlier ones too, the town, or even full address of the family are entered. I use this field to record this information. I am quite happy to use abbreviations such as: St. - Street, Rd. - Road, Cott. - Cottages, etc. as this takes up less space in a final print. Sometimes addresses may be quite long, e.g. 56 Parkinsons Road, Basford, Nottinghamshire especially where the address is not in the same parish as the baptism, and therefore I tend to use an abbreviation such as Basford Notts., and then put the full address in the notes column.
In many registers after 1813 the Quality, Trade or Profession of the father is usually stated. The field name Trade is a catch-all for these. (Quality, by the way, is often used where the father was a Gentleman). Again, long descriptive occupations are expanded in the notes column. Occasionally, earlier register too may state an occupation
This column is used to record any additional notes, especially margin notes written in the register. I also use it to expand details which may have been abbreviated in other columns. As this field may sometimes contain quite a lot of information, I usually set the data type as a memo field rather than a text field. On most databases, the maximum number of characters allowed in a text field is 255, and sometimes we need to exceed this.
The use of commas and quotation marks
It is very tempting to enter data such as: Margin note: Illegitimate, or 13, High Street, Newent Commas or quotation marks should never be used in a database! It presents a big problem if the data needs to be exported into a different database software. I prefer to use Microsoft Access as my database software, but not everyone else does, furthermore, others may have different types of computers.
There is a standard for transferring data between different databases, and this standard has existed since computers first began to be used. Every database can import files of this standard. The file type is known as a Comma Separated Variable file. CSV file for short. It is a simple text only computer file. Each field of data is separated by a comma, and enclosed in speech marks. It looks something like this:
No,Birth date,Baptism date,First
name,sex,Father,Mother .... etc.
So if our data contains commas or speech marks, then it is impossible for it to be transferred sensibly to a different database or a database in a different type of computer. Well, not quite impossible, but it entails hours of work editing the CSV file to get rid of all of the extra commas and speech marks. Believe me, it is a pain!
Top of this page (Baptism Records)
Copyright ©1999 Rod Neep