Note: Text covers an earlier version. |
Merge Competitions and Distributed Event Centers
Sometimes you need to divide event center into several locations (or different occasions). Maybe you want young people in one place and difficult classes in another. Or a relay that goes from point A to point B with a different finish for each changeover. It can be difficult or impossible to set up a common local network. Then you can exchange data between the different MeOS systems manually, by sending files (either via some web-based file sharing service or through running USB memory couriers)MeOS supports importing and merging changes made to independent copies of the same competition (or even completely independent competitions, if they are based on the same set of courses). The function can be found under Merge Competitions on the page Competition.
The most common arrangement is to have a main secretariat and one or more distributed secretariats, where each can have its own local network with a number of computers. The competition is prepared as usual, and exported to a file, which is imported at each location. This is the common base version.
Now you make changes to the competition on the different systems, e.g. add new entries or read out cards. To merge the competitions, producing a common version including all changes, proceed as follows:
- Export a (new) copy of the contest, including changes, at a distributed secretariat.
- Transfer the copy (as a file) to a computer at the main secretariat.
- Click Merge Competition and select the file and Continue. Information about the file is displayed. Check that it look correct and press Merge.
- Changes are incorporated into the current competition, but first a local automatic copy of the competition as it looked before the merge is created (in case something goes wrong).
Two Ways to Merge Data
If you start from the same base competition, MeOS compares the imported competition with the previous version to see what changes have been made, and makes these changes in the current competition. In this way, runners deleted in the imported competition can be removed and to some extent changes in data belonging to the same runner can be handled. If you want to avoid deleting data, you can deselect Allow removal of competitors (etc) in the last step.If you want less sophisticated update but rather a pure merge, e.g. if different runners have run the same competition on different occasions and you have a total result, it is better to create a completely new competition and merge all sub-competitions. When you do this, you get a warning that there are different basic competitions, but if that is what you intend, the warning should be ignored.
Note
It is important that the different secretariats do not make changes to the same part of the competition. There should be a strict division into which classes or legs are handled by which secretariat. It is also important that everyone who works with MeOS understands this. If two secretariats make changes in the same part of the competition, for example the same competitor, certain changes may be overwritten during the merge.
It is important that the different secretariats do not make changes to the same part of the competition. There should be a strict division into which classes or legs are handled by which secretariat. It is also important that everyone who works with MeOS understands this. If two secretariats make changes in the same part of the competition, for example the same competitor, certain changes may be overwritten during the merge.
MeOS Insight
If you have more than two secretariats, either one (A) can be the main secretariat and the other: (B), (C), (D) are distributed. Then you exchange information between (A <-> B), (A <-> C), (A <-> D), but never directly between for example (B <-> C); all information from (B) to (C) goes via A.
Another possible variant for exchange is (A <-> B), (B <-> C), and (C <-> D) in a chain, whereby it is not allowed to transfer data directly between, for example (A <-> C ). In order to get over a change in D to A, it must first be transferred to C (from D) and then to B (from C) and finally to A (from B).
If you have more than two secretariats, either one (A) can be the main secretariat and the other: (B), (C), (D) are distributed. Then you exchange information between (A <-> B), (A <-> C), (A <-> D), but never directly between for example (B <-> C); all information from (B) to (C) goes via A.
Another possible variant for exchange is (A <-> B), (B <-> C), and (C <-> D) in a chain, whereby it is not allowed to transfer data directly between, for example (A <-> C ). In order to get over a change in D to A, it must first be transferred to C (from D) and then to B (from C) and finally to A (from B).
To post a comment, you need to log in.