Section 4.4 - Compiling registrations - details
When registration is done on multiple computers, each one will have saved on it (in the project directory) a registration database. For a project named project_name and 3 computers that were given registration IDs 1, 2, and 3, you will create the combined database by merging the files project_name_registration_1.json, project_name_registration_2.json, and project_name_registration_3.json.
All of these files are put on one computer (we use a USB flash stick), and are then merged using the "Compile" module in fsTimer. The "Add" button is used to select the files that are to be merged:

The "Remove" button removes a selected filename from the list. When all of the registration databases to be compiled are on the list, then press "Merge". The "Merge" operation will create two new files: A merged registration, that will be saved as project_name_registration_compiled.json, and a timing dictionary, that will be saved as project_name_timing_dict.json. The merged registration is a normal fsTimer registration database file that could be opened, for instance, in the Registration window. It contains all of the entries from all of the compiled databases. The timing dictionary is a dictionary that allows fsTimer to look up runner information (name, age, and gender) by bib ID. When a runner's bib ID is entered into the Timing module of fsTimer, it will use the the timing dictionary to look up what the corresponding name, age, and gender are. Under normal operation, pressing merge will work nicely, the registration databases will be combined and the files written:
In some instances, fsTimer will find a particular type of error in the registration databases. The particular error that it checks for are
overloaded IDs. This means that the same ID was (in the registration databases) assigned to multiple runners. For instance, ID "110" might have been assigned to "John Smith" in project_name_registration_1.json, and assigned to "John Doe" in project_name_registration_2.json. This is an issue when forming the timing dictionary, because now when fsTimer wants to look up the information for bib ID 110, it doesn't know if it should use John Smith or John Doe. If fsTimer finds overloaded IDs, it will raise an error and tell you:

Notice that on the Compile window it now says "Errors found!" in red on the bottom, and a new window has popped up with a list of the overloaded IDs. In the above screenshot, IDs 110 and 120 were overloaded, meaning that they were assigned to multiple entries. We should briefly note that this means unique entries - if the same ID is used in multiple registration database files along with the same other information (Name, age,... all of the registration fields), then this is not a problem.
For medium to large races of more than 100 runners, it is quite likely to have overloaded IDs due to entry error by the people running the registration computers. If you click on an ID and press "View ID entries", it will bring up another window that will list for you the conflicting registration entries:

In the image above, we see that Willie Hansen and Nicholas Dyer were both assigned bib ID 120. When this happens, there are two ways to proceed. If you know which of the entries is the actual runner with bib 120, then you can select that entry and press "Keep entry". For example, selecting Willie Hansen and clicking "Keep entry" will mean that in the merged database (and the timing dictionary), Willie will have the ID 120, and Nicholas will be left with a blank ID field. Usually, however, you will not know which entry is the correct one. In a real race scenario, the time interval between closing registration and starting the race is usually pretty short (we close registration 15 minutes before the race starts), and so there simply is not time to figure out which is the correct entry. In this situation, just press "OK" and then press "OK" in the overloaded IDs window:

When you press "OK" in the window above, it leaves all overloaded IDs unassigned. This is the right thing to do, unless you actually know which are the correct entries. When the runners cross the finish line, they will still show up in the results, they will just show up by bib number alone, and without their name, age, and gender. Unfortunately this means that they will not show up in the divisional results, but this is something that you can correct after the race when you have time to actually figure out what the correct entries are.
Pressing "OK" in the overloaded IDs window will unassign all of the overloaded IDs, thus allowing the merging and creation of the timing dictionary to continue.

The Compile window will then say at the bottom "errors corrected" and will print the names of the compiled registration database file and the timing dictionary file.
In addition to the timing dictionary and the compiled registration database in fsTimer format, fsTimer will also save a csv spreadhseet containing the merged registration information to the file project_name_registration.csv. This is useful for giving the final registration information to the race director, to use for contacting people the following year.
As a final note, as was mentioned in
Section 2.4, even if there is only one registration database to be used for timing (i.e., there is nothing to merge), you must still compile that one registration database so as to create the timing dictionary.
Continue on to
Race timing - details.