| Transcribing Parish Registers
Index Introduction
Recording Baptisms |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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
database file.
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), “Child’s Christian name”, “Parent’s 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
not listed.) 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:
1 Birth Date 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 doesn’t 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. Baptism Date Again, in the date format as above. Sort Date 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 can’t 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. First name 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. Sex 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. Father Used for the father’s 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 father’s name is not stated, then I use a dash “-”. (We cannot always assume that if the father’s name is not stated the child is illegitimate, for example, the father may have died). Mother Used for the mother’s Christian name. The advantage in using separate fields for the father’s and mother’s 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 father’s 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 mother’s 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 mother’s maiden name. I have even seen examples where the mother’s 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 “Mother’s surname” field, and then in the “Notes” column, enter “formerly Jones”. Again, I do not assume that if only a mother’s 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. Abode 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. Trade 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 Notes 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)
Index
Copyright ©1999 Rod Neep