Ancestor+

Ancestor+

Database Tools

The Tools menu

The Database Tools menu is accessed from the Main menu. It has various items which perform actions on the entire database. As they act on the whole file, and sometimes on the Resources directory as well, do not use any of these until you have read the following section and thoroughly understand exactly what will happen and the implications for the database.

Lower case

Most people type in data in mixed case, ie. names, places, etc. would have a capital first letter and the rest in lower case. Sometimes data may be all in capital letters, particularly if it has been imported from another program. This normally looks very untidy and can be difficult to read, especially in reports and charts.

If you select 'Lower case' the program will examine every name field (Surname, Forename, Title and Byname) and every place field (places of marriage, birth and death) and change all text in these fields so each word begins with a capital letter with the rest in lower case.

This may not always be correct, but it will be in most cases. For example, 'JOHN SMITH' would become 'John Smith', but an abbreviation like NZ for New Zealand would become 'Nz' (unless written as 'N.Z.', in which case it wouldn't be changed). Existing lower case words will not be 'capitalised', so, for example, 'Stockton on Tees' wouldn't change, but STOCKTON ON TEES would become 'Stockton On Tees'.

Though imperfect, the results will be a lot closer to the desired effect that the unaltered data. Any errors can be discovered by inspection and corrected, which will be much less work than altering every record manually.

Sorting by date

The following functions perform various types of sort based upon dates. Before you use any of these you must understand that the program can only do this meaningfully if there is a date. If no date for an event is given then the program, for the purposes of sorting, would regard the date as 'year zero'.

For example, earlier it was described how to sort children by date of birth. If there were three children and two had a date of birth but the third did not, then the child with no date of birth would appear first after sorting. This might not be correct, but if there's no date the program has no way of judging where that person should appear.

Child sort

This searches every family record and sorts all children into order by date of birth. It is directly equivalent to what happens when you do this from the Family window, but the operation is carried out on the entire file.

Partner sort

Like the Child sort, this is directly equivalent to the normal operation of sorting spouses by date of marriage. Again it will operate on the entire file, sorting all multiple marriages or partnerships.

Sort by DoB

This will sort the entire file by people's date of birth.

As each person or family is entered into the database they are allocated a number. Normally, therefore, person No. 1 would be the first person entered, No 2 the second, etc. The only variation in this sequence would be when a person or family is deleted and the old number used for a new person or family. The reference numbers therefore have no direct significance. In fact, as it is usual to work backward from the present they would tend to be in reverse chronological order. The only time the numerical order of records is significant is when compiling reports. These are normally created in numerical order, and it may be preferred to have them in chronological order.

This facility will sort the entire file in order of the date of birth of each person. This means that the person with the earliest data of birth would become No. 1 and so on. As a by product of this anyone with no date of birth would move to the start of the file, and deleted people move to the end. In fact, no physical moving of records takes place, the numbers are just re-allocated, which makes the sort extremely fast.

It is extremely important to understand the significance of this action. The probability is that the reference number of every person in the file will change. If you have any paper records, cross references, or any other material which refers to people in this file by number then these references will become invalid.

This would also apply to the Resources directory. Inside each section of the resources directory, the Families and Person sub-directories, each person and family has its own directory, identified by being given a number. The same number as the record number of the person or family. So if the number of the record changes, then in order to remain 'in step' with the database the number of every directory in the Resources directory will have to be changed. Not only will it need to change, but because of the (pre RO4) limit of 77 files per directory these directories are further sub-divided into sets of 77. So, if person number 10 before sorting becomes person number 94, not only will the number of their resources directory need to be changed, it will have to be moved from its original position in the first set of 77 directories to the second set.

Sorting the Resources directory is a major step, but as will shortly be shown, you may not need to do it. After sorting the database itself you are offered the option of sorting the Resources directory. If you decline then it will not be altered. This will mean that the numeric references in the database won't correspond with those in the Resources directory, so if you really do want to sort the whole file, and retain it in its sorted condition,you will need to sort the resources directory as well.

Bearing in mind all the implications of sorting a file in this way, especially those concerned with paper documentation, it is not an operation to be lightly undertaken. However, it can be extremely useful.

For example, if you have a file in it's natural, unsorted state, but want to compile a report of all the people in chronological order you can do so without permanently sorting the file. First, if you have made any changes to the file since it was last saved you should Save it. Select 'Sort by DoB' from the DBase Tools menu but, after sorting the file, do NOT sort the Resources directory. Now compile your report, which will be in chronological order. You can now discard the sorted file and revert to the last saved (unsorted) version. The obvious problem with this is that you cannot include any Notes in your reports as the Notes files are in the resources directory which will be out of sync with the database.

To make sure that you don't inadvertently save a sorted file and overwrite the unsorted version when doing this the filename in the Save window will change to 'Sorted' after performing a sort operation of this type.

If you want to include Notes from your Resources directory in reports you won't be able to do it this way because the numbers in sorted version of the database won't correspond with the unsorted numbers in the Resources directory. You have two options if you need to include Notes. You could make a complete copy of the Resources directory, using a slightly different name, and ensure that the name for the Resources directory in the Database Choices window is changed and set before you carry out the sort. You can then sort the Resources directory but it will be the copy, not the original, that is sorted. This is absolutely safe because your original Resources directory isn't changed, but it might take some time (and disc space) to make a copy of the Resources directory.

The second method is to first sort the file and Resources directory and then unsort it again. This is theoretically possible, but a successful 'unsort' requires the file to be in a certain state before the sort. See the later section on Unsorting for more details.

Remember you can sort the actual database but the change is not permanent until you Save it because you have only sorted the version held in memory, you haven't changed anything in the version on disc, so if you discard the file (select Clear DBase from the main menu) you can simply re-load the original, unsorted, version.

However once you begin to sort the Resources directory changes are made to the actual files on disc. You can't revert to the original just by selecting 'Clear DBase'.

Family Sort

This is similar to sorting people by Date of Birth but is sorts partnerships by date of the marriage or start of the partnership. Exactly the same system is used, and as with sorting people you can choose to sort the Resources directory as well if you wish.

As it works in the same way all the same warnings apply.

Unsort all

Seeing this option on the menu you might think the earlier warnings about sorting can be taken lightly because it can be undone. Well, possibly, but perhaps not.

Under most circumstances it is possible to reliably sort and unsort the file and Resources directory and after the operation all the reference numbers will be exactly the same as in the original file. To understand how this can be made to work you first need to understand how data is stored and number s allocated.

The database consists of a series of records held in memory one after the other. The first record created will be given the number 1, the second number 2, and so on. As new records are added they are attached to the end of the file and the next available number allocated. So, in its 'natural' state the number of each record corresponds to its position in the file. Even if a person or family is deleted the number remains, and if it is re-used the new person will occupy the same place in the file.

When the file is sorted the records aren't moved, they are just given new numbers. In theory, therefore, it is possible to restore the file to its original state by working through it allocating number 1 to the first record number 2 to the second, and so on to the end. This should return the file to its original, ordered, state, and while it is doing this the program can work out how to change the Resources directory to suit.

So, unsorting does not return the database to its state before it was last sorted, but to its original state when the records were entered. If you sorted it on a previous occasion it will not revert to that state. If you had paperwork cross referenced by number to the database after the earlier sort, those references will be wrong.

There's another potential trap which could result in a thoroughly scrambled Resources directory that you would have to spend a lot of time and effort sorting out manually. The sort/unsort sequence will only work if you either sort the Resources directory with both operations or with neither. If you sort it and then forget to unsort it you've got problems. If you don't sort it but then tell the program to unsort it you've got problems.

One final (but unlikely) possibility is a disc error. This could interrupt the sort or unsort before completion. This won't matter for the actual database because the Resources directory isn't dealt with until after the file sort/unsort is complete, but it will leave the Resources directory in a mess.

As you can see from this the best way to organise your data is to leave it unsorted. If you know your file is unsorted then you can (probably) sort and unsort it and the Resources directory without problems.

Despite all the warnings, you will see that the problems arise because of the possibility of the internal reference numbers in the database getting out of step with external references, either in the Resources directory or paperwork. Whatever happens, the actual data should be perfectly safe, it's only the external cross referencing that can get mixed up.

APDL