By Rod Neep
|Transcribing marriage registers into a database throws up some interestuing
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 1700s 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 landcape format (see example above).
The data fields included in my marriage databases incude 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.
|The Database Fields Used
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.
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 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.
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.
Groom First name (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.
Groom Surname (GroomSurname)
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!
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".
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 "numerica" data in the database design.
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!)
Bride First Name
As above for Groom first name.
As above for Groom surname
As above for Groom age
As above for Groom parish
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.
In the example databases which you can download, you will find a final field called "More". My early databases did not inlude 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:
Copyright ©1999 Rod Neep