Recording Burials

By Rod Neep

So what separate items of information (fields) do we need for a transcription for an event such as a burial? Furthermore, what information is available in a burial register? The answer to the second question governs the answer to the first. Unfortunately, different burial 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 buried 27 June 1779”. In later parish registers, we find a pre-printed page with columns of information, including entry number, “Name”, “Abode”, “When Buried”, “Age”, and a final column “By whom the ceremony was performed”. In addition, it is not uncommon for the vicar to add other notes.

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..

It helps in presenting the information in printed form to have the information in a certain order, so that it reads easily and makes sense, and this also governs the order of the information in the database.

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 below, that I use a four digit number, as some pre-printed registers for larger parishes go above 1000.

Burial Date

Format: dd mon yyyy/y e.g. 20 Jan 1834 or 20 Jan 1701/2

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.

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 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 burials have been “added” at a later date. In final prints of course, the sortdata column is omitted.

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 person. 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 fashioned 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.

Relationship

This is an additional field , in which we can enter information such as “wife of John”, “son of John & Mary” etc. In most earlier burial registers this information is stated, although surprisingly, it may not be noted in later registers when the pre-printed forms are used.

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!

Age

The age at death. The following examples of abbreviations are used:

12	years ( a whole number used alone)
2y6m	years & months
2y6m3d	years, months & days
3m	3 months
3w	3 weeks
3d	3 days
3h	3 hours

Note that this is entered into the database as a simple “text” field. We cannot use it for calculations, but a numeric field type would not be able to accept the data in the format “d” or “m”.

Abode

In later registers, 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.

Notes

This column is used to record any additional notes, especially margin notes written in the register. Sometimes, a burial register may give an occupation of the deceased, and so this is entered into this field. 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.

An example of a final print of part of a burial register transcription (Minchinhampton, Glos.)

Creating an index

If the data is in a database, then creating an index is very simple. What we need is a query of the data with the fields in the following order:

Surname sorted alphabetically ascending
First name sorted alphabetically ascending
Date
Sortdate in ascending order, but not displayed

The result being something like this.

(part of the index of burials for Parkend, Gloucestershire)

Below: an example of the database as entered, from an early burials register without entry numbers:

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.
“0001”,”20 Jan 1875”,”26 Mar 1875”,”John”,”son”,”James”,”Mary” ... 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!