Transcribing marriage registers into a database throws up some interesting little problems, not the least of which is where to stop with all of the information available in the register. What to record, and what to leave out? I strike a compromise, on the basis that an abbreviated transcription can act as a “starter”, and interested people wishing more information can then look in the actual register. Early registers are simple, they have a statement such as “John Smith and Alice Jones were married”, or if one of the couple was from a different parish, “John Smith p. Ruardean and Alice Jones”. I think that this additional information of the parish of origin of one of them is valuable initial information which gives a pointer to further research.

Some registers from the late 1700’s begin to give the names of witnesses, and they are almost always present on the post 1753 registers, but I leave these out of the transcript, and I also leave out the post 1837 details such as address, and names and occupations of fathers. The problem with including everything is simply one of space available in a final print of the data. As it is, the details included fill in the full width of an A4 page in landscape format (see example below).

The data fields included in my marriage databases include the fields as illustrated below. The small “x” added after a name represents that the person signed the register with an “X” mark rather than a signature - just an added piece of information. In the “Age” field, I may have to insert “minor” (if stated as such in the register) or “full”, representing “of full age”, i.e. over 21 years. All fields have a data type set to “text” format.

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 the marriage of a couple (or all people with the same surname) 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, 10, 11, 111, 112... 2, 20, etc.

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

Bride/Groom First name (Bride/Groomfirst)

This is simply the Christian name of the groom. 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.

Bride/Groom Surname (GroomSurname)

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!

As an added piece of information I usually add a lower case “x” after the surname if the person signed with an X mark instead of a signature. However, when doing searches on the database, one must then enter the search as, for example NEEP* rather than NEEP. The wildcard takes care of the trailing “x”.

Bride/Groom Age (G age)

This is not usually shown in early registers, although you may see “of full age” or “minor” (under 21 years), in which case I enter “full” or “minor”. Later registers usually give an age in years. Note that this field should be set as a “text” data field, and not “numerical” data in the database design.

Bride/Groom Parish

This field is often left blank in the database. However, if the groom was from a different parish than that of the marriage, then the clergyman will virtually always record it. It is a useful piece of information to record! If the parish was one in the same county, then I will normally state just the parish name, however, if it was in a different parish, then I would use something like “Matlock DBY" - using the Chapman county code. (Note - never use commas in a database!)

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.

More

In the example databases, you may find a final field called “More” to be useful. My early databases did not include this, but I found it useful.

When you make a printed report of marriages, it is impossible to get it all to fit onto even a landscape A4 format if all the fields are included. Therefore I will omit the fields "Groom Parish", Bride Parish" and "Notes". But I do include the narrow column "More", which simply has an "X" entered into it if there is more information in the database.

Anyone seeing the printed report will therefore know that they will need to look at the original marriage register (or ask the person with the database) for further information.

A printed report will show: