Addendum 2 – Data Entry, Editing, and Validation

Data Entry and Editing

The primary purpose of this module is to allow us to enter, edit and check rating reports so they are ready to be rated. Most of this module is just duplicating the current dbase module in a modern database. Please review the Chess Federation Rating System - CFRATSYS (appendixes A, E1, and E2) for an understanding of how our current system works.

It is very important to note that changes to the structure of the edit files and the electronic submission files has been recommended. It may not be necessary to implement the new structure or import files immediately. This can be accomplished after the main portion of the program is tested and working but a completion date does have to be provided. Please review the Proposed Report on Disk Changes for a description of changes we need. As the validation program has several requested changes based on the new format, this will have to be carefully evaluated. It may be necessary to have a validation tailored to work with both the old and new format and carry out functioned based on the specific information available.

The current program uses a screen entry system where only the event and one section header is displayed at a time. Additionally, when the tournament results are entered, only one pairing line is displayed. The concept of displaying only one pairing record at a time is possibly a good idea as it makes mixing up the data more difficult. However it does make viewing the entered data very difficult. The suggestions of the programmers are very welcome. Flexibility in screens for entering and viewing the data in the edit files will be greatly appreciated.

Maximum use of techniques such as automatic advancement to the next field when the previous field is completed should be provided. Additionally, data verification should be used where applicable. ID numbers and opponent #s should be checked for range. Results in a Swiss Cumulative (SCUM) report should be checked that an increase of between 0 to 1 occurs. An important error check is needed when entering ID numbers. The first 2 letters of the last name should be required during manual entry. This should be compared to the looked up last name for the ID and an audible and visual warning should occur if they do not match. This should happen both during initial entry and also if the ID number was changed. The current program will set the field size for opponent # based on the header value for last pairing number. An 8 player event will have room for only one digit. An event with only 5 rounds will only show data entry fields for 5 rounds. This saves a small but valuable amount of time when entering data.

Improvements to current functions:

The current program does not include the capability for the following and it should be included if reasonable. This refers to events not rated yet.

1. Although infrequently needed, the capability to move a section from one event to another is useful. It may result in one event disappearing. This is not a concern as long as items such as the Event Tracking Log are properly updated. The converse, removing a section from an event and making is a separate event is also just as useful. Procedures such as using the original values for the section and event as default values are also appreciated.

2. Data entry for SCUM events should be made easier by using a single key such as the + key to be read as entering a .5 to the initial value. As an example, if the operator wanted to enter a 1.5 they would just enter "1" followed by the "+" and the program would place 1.5 in the field. For some reason, the current system uses 2 places after the decimal. This is not necessary and should not be retained.

3. The current system does not provide any capability to see an overall view of the data for a section in the edit files. A view and print capability should be included. The user would specify either an entire event or just a section and a crosstable like report should be displayed.

4. It often happens that a tournament run as a Round Robin is reported in a Swiss format. The ability to convert designated sections from Swiss to Round Robin is also useful.

5. The ability to enter double or triple round robins does not exist. Either direct entry or just a special module to convert double or triple Round Robins to an appropriate file for entry is also desired. This does not occur too frequently but would be greatly appreciated.

Tournament Validation

The primary purpose of this module is to verify reports and identify problems for correction before the event is rated. It is my opinion that this must be here and not as part of the rating process. This is true for two reasons. 1^st, the "watch" items must be checked before the event is rated so errors can be corrected. Second, it appears a safer way to insure that the rate will not have problems. The rate will require many computer resources and time. It will run much faster if the validation is already done and more importantly, may run with much less chance of causing problems in the rated event files.

The validation process is discussed in the description of the current system and the requested changes are noted there. Please see appendix C in the CFRATSYS description for details. Many of the requested changes will require modification to the current file structure. This will include the necessity to provide for format conversion. This is discussed primarily in the description of the current file structure in appendix E to the current system description.