Entering and Editing Tournaments
A description
of our current system
This appendix describes the
way our current system works for entering tournaments both by hand and by disk.
Although this is a description of our current system, I have noted some improvements
and also request your consideration of improvements, especially in areas that
will improve our accuracy and speed of data entry. Most fields have a provision for contextual
help when the F1 key is depressed. Using F2 to look up membership information
by displaying an alpha list sorted by name is supported in all three areas. One
improvement would also be the ability to display an ID number list
One
important item to note is my request for modifications to the file structure
and changes in which file certain items of data are kept.
This
section covers the following areas and deals with
1. Entering an
event by hand
2. Editing an
entered event.
3. Entering disk
reports.
Edit File
Structure
As
events are entered into our database files, they are kept in a separate edit
database. This database is comprised of three files. They are:
Tnmtevnt.dbf
see E10 pages 1-2
Tnmtsect.dbf
see E8 pages 1-3
Tnmtdetl.dbf
see E11
Pages
E8, E10, and E11 are partial printouts of the data contained in these files. Page
E9 is a printout of the validation report. This printout contains the status
codes (called status sysbols table in the report) used in the section file as
well as a status codes table that explains the codes used in the validation
report.
Additional
information about the edit file structure is available in Appendix F concerning
the files submitted on disk rating reports. These files are exactly the same
files as listed above except that they have to be merged with our files for
editing and
For
the operator to enter a tournament by hand, they have to input the events
ending date. Once the ending date is entered (see E1 and E2), the edit mode is
entered and the operator continues to enter the header and section information.
If the entry process is stopped before the section records are entered, the
computer will not create a record in the database and all previously entered
data will be lost. All the section records must be entered before the operator
can quit without losing entered data.
Because
the event ID number is used as the index in the current system, the ending date
cannot be changed once the event entry is started. To change the ending date,
the event must be deleted and reentered. We want to keep the event ID for
filing and ease of lookup purposes but would much appreciate an easy automated
method of editing the ending date.
This
page shows an event where only the tournament information is entered and the
section information has not been started. Most of this information is
self-evident. Dates are checked to insure that silly errors such as an ending
date in the future or a starting date after the ending date. All this
information corresponds to fields found in the tnmtevnt.dbf file.
Data
entry occurs in the following order
2.
Date Ended:
automatically entered when the date in entered as show on pg E2. This cannot be
changed.
4.
Sections: 0 to
20. Operator enters how many sections
are included in this event. Request extend range to 99
5.
Scholastic: Y or N.
Note I have requested to move this to the section file
6.
City:
7.
State:
8.
Zip: computer
checks zip against state and will not allow operator to leave header area until
they match.
9.
Country: USA or
other. We do have some events run out of country.
10. Affiliate ID While in this field, the operator
can depress F2 which brings up a alpha search list
11. Aff. Prefix: two letter field where the operator
enters the first two letters of the affiliates name. The program then checks
the associated field for the affiliate in our records and compares that data
with the information entered by the operator if there is a difference, an error
screen is generated and the operator is asked if they want to correct the data.
12. Send C. Table to: A, T, or N. A is affiliate, T is chief TD, and N is none.
The
computer will ask the operator to complete the correct number of section
screens based on the number of sections indicated in the event header. Again,
the fields are mostly self-explanatory.
This data is stored in the Tnmtsect.dbf file
1.
Section name:
Optional,
often left blank for events with only one section.
2.
Total rounds: - range is 1
to 20
3.
Last Pairing: - Range is 2
2000 for swiss and scum events, 2-20 for RRs and only 2 for a match.
Occasionally an organizer will submit an event where the pairing numbers do not
start with 1. An example is in a two round event, the first player in the first
section will be numbered 100 and the first player in section 2 starts with 200.
Another type is where the first number for section 2 follows the last number
from section one. The program will allow the operator to input events where a
series of pairing numbers remain empty.
4.
Tournament
Type (s/c/r/m): s = swiss, c = cumulative, R = round robin, and M = match
5.
K(F/H/Q):
6.
Rating System
(R/Q): -
if K=Q then RS must be Q.
7.
TD ID: - optional
8.
Prefix:
9.
ATD ID: - optional
10.
Prefix:
Both prefixes are the same
as for the affiliate prefix in the event section. They are used to check for
data entry errors. Operator can ignore warning. Remember that the tournament
type refers to the data structure rather then the actual type of tournament.
Detail Area:
The
layout and key entry codes for the detail (results) input screen change based
on the tournament type selected in the section header. All entry is
accomplished on a single player basis. You can edit or enter the player results
either by saying Y to the question Enter tournament results now? after
completing the section entry procedure or go directly to a specified section in
the edit mode. Pages E5 to E7 show sample results entry.
Pairing
Number:
When
the screen appears, the pairing number field is highlighted so the operator can
either depress the enter key to work on that player or type another number to
enter data for a different player. An
automatic entry of the next logical pairing number is done by the computer. The
operator can depress the enter key to enter data for that pairing number or enter
any valid pairing number to enter data for another player. The data does not
have to be entered or edited in a sequential sequence. Once the final pairing number in the section,
a screen asking which section or event to be next worked on is displayed.
The
program has error checking that will not allow a pairing number greater then
the last pairing number in that section. The program will not notice nor care
if not all the pairing numbers are used. It will pass validation as long as no
one was listed as having played against one of the missing numbers.
ID Number:
The
ID number is entered by the operator. This field will not allow the entry of
non-numeric characters. Once all 8 digits are entered, the cursor proceeds
automatically to the prefix field. This field can be bypassed to continue data
entry and entered later when an ID
number has been found or created.
Prefix:
The
first two letters of the players last name are entered. The program then looks up the data for the
given ID number. If the looked up data and the prefix match, the name, rating,
and state are automatically entered into the record and the cursor is
positioned in the SCORE field for round 1. If they do not match, a beep is
sounded and a question Correct unmatched player data (Y/N)? is displayed.
Normally, the operator will correct that data now, but is allowed to bypass the
recheck if desired.
Last, First,
Rating, and State are not data entry fields. They are displayed as
information for the operator. It would be a great improvement if membership
type and exp. date were also displayed.
Score and
Opponent data entry:
This
areas processes vary depending on the tournament type. The data entry for each type of data is as
described below. For all types, the file size and error checking will depend on
information entered earlier. Only the correct number of rounds will be
displayed. If the last pairing number was =< 9, only a one digit opponent
field will be used. Between 10 99, a two digit field is displayed and between
100 999, a three digit field is used. During data entry, as soon as a field is
filled, the cursor goes automatically to the next field. If the operator is
entering 8 in an event with a last pairing number greater then 10 the enter key
is then depressed to advance to the next field. Error checking prevents entering
an opponent number greater then the last pairing number listed in the section
header. Once the final data item is
entered for a given player, the program asks any changes? Y/N Answering Y
repositions the cursor back to the round 1 score field. Answering N clears the
screen, repositions the cursor in the pairing number field and automatically
displays the next pairing number in the section. If the previous pairing number
was the last pairing number in the section, a window appears that allow the operator
to go to any of the next sections. If the final section was finished, in enter
new tournaments, the ending date window for new entry or select tournament
window in the edit mode is shown so the operator can either enter or edit
another event.
The
following describes the differences in entering the various types of
tournaments.
Match:
The
simplest data entry is the match. Only
one round is displayed regardless of the number of rounds entered in the
section data. The operator enters the total score for that player and the
program then goes to the other player. His score is also entered. When
validation occurs the sum of the two scores is compared against the number of
rounds entered in the section data.
The
computer automatically enters *** in both opponent and score for the opponent
number equal to the pairing number. It also enters all the other opponent
numbers so the only data entered by the operator is the score against each
opponent. The operator enters one of the following codes.
1
= win, 5 = draw, and 0 = loss U =
unplayed zero F = unplayed forfeit
zero, X = unplayed forfeit win, B = full
bye, H = 1/2 point bye, Z = unplayed forfeit draw
Note
that 5, not .5 or 0.5 is entered for a draw and the computer converts the
result to the standard code.
The
operator has to fill in both result and opponent. The result codes are:
W
= win, D = draw, L = loss, U = unplayed zero F = unplayed forfeit zero, X = unplayed forfeit win, B = full bye, H = 1/2 point bye, Z = unplayed forfeit draw. When one of the unplayed game results are
entered, the operator has to enter a zero in the associated opponent field. We
would appreciate if the new program would do this automatically and reposition
the cursor in the next field.
The
operator has to fill in both result and opponent. The result codes are:
Score
is a numeric score for all played games. For some reason, the current program
uses 2 decimal places. I sincerely hope this can be changed to 1 place in the
new program as 0 & 5 are the only two possible entries after the decimal
point. Unplayed games are entered in the same manner as in the swiss format.
Double round
robin:
There
is no possible way to enter a double round robin in the current system. This
form of entry needs to be created for the new system. These can be submitted as
either results for 2 single games or just a combined score. This has major
problems associated with the way the event is reported and entered and more
work needs to be done to figure out how to accomplish this entry process. I
believe we will need to create a proper form to have this type event reported
in a manner needed for proper data entry.
2. Editing an entered event
This
is almost identical to the enter mode except the screen as shown in E2 is never
seen. The operator will be asked to
enter the event ID number and section number. If a section number of 0 is
entered, the header sections are presented for changes. If a valid section number of 1 or greater is
entered, the program immediately opens the individual player screen for the
designated section and starts with the lowest entered pairing number. The data
entry procedure is identical to the methods used in data entry.
Significant
changes can be made to the event and section information previously defined
when an event was entered by hand or by disk.
Changes
in the # of rounds or last pairing number will cause changes in the record
structure of the detail data base. If the numbers are reduced, the data for the
valid rounds or pairing numbers is kept and the extra data truncated.
If
the tournament type is changed, all data in the detail database is eliminated
and must be reentered.
If
a section of an event needs to be deleted, the change is made using the
override status capabilities in menu item 6 of the mail menu. A section can be
added by editing the event header and increasing the number of sections.
Occasionally,
especially on disk reports, events will have several players who never played a
game in the event. In the edit mode, as the cursor is positioned in the pairing
number field, the operator has the option of depressing the F8 key. This will
delete the player involved. The pairing numbers for the other players are not
changed. If the operator then goes to an
earlier pairing number and comes to the deleted player, that number is skipped
when the automatic update of the next pairing number is done. An accidentally
deleted player can be reentered by manually typing the missing number in the
pairing number field. This will allow reentry of the detail data.
3. Entering
disk reports.
Rating
reports on disk consist of the same three files as are used in the edit
database and they also have the same name.
When a TD submits more then one event, they will place each set of 3
files in a separate sub-directory. This is why it is necessary to specify the
sub-folder. The default assumption is that the 3 files reside in the root directory.
When
the option to enter tournaments on disk is selected, the operator is presented
with a screen (screen 1) where they must enter two items of information.
Drive
location. A or B is entered and
provision is made to include a sub-directory. Once the correct data is entered,
the enter key is depressed and the cursor moves to the date received field. The
first time this is displayed, a default of b:\ is displayed.
Date
Received The operator enters the date the disk report was received. The enter
key is then depressed.
A
new screen (Screen 2) appears that indicates as each of the three files are read
into the computer. Once the files are read, the event name is displayed and the
newly created Event ID number is displayed for the operator to record on the paperwork.
When
the operator is ready to continue, the enter key is depressed and screen one is
again displayed with the cursor set back in the drive location field. The
information from the previous entry is retained as a new default and depressing
the enter key will accept that information. This allows the operator to just
depress enter twice to read the next disk unless it is necessary to change the
received date or subdirectory.
The
sequence of alternating between the two screens continues until the operator is
done entering disks and escapes out of the disk entry sequence.
The
program will not accept disk input from disks with corrupted data or bad dates.
These disks have to be fixed using dbase III and other techniques for dealing with
damaged files. If the fix is successful, the disk is reentered. Occasionally, a
pointer is bad but the disk will be successfully read into the edit database.
In this case, when the validation is run, a dr1?? Error results and the records
are marked for deletion.