Appendix E1 TA and Edit File Structure

Description of the Dbase III files and procedures used to submit reports on disk.

It is important to note that the Tournament Administrator (TA) files are identical to the files used by the USCF rating system Entry and edit module (CFRATSYS). Therefore, this explanation also describes the file structures for the Edit module of the CFRATSYS. These files correspond as follows:

TA program CFRATSYS

Thexport.dbf Tnmtevnt.dbf

Tsexport.dbf Tnmtsect.dbf

Tdexport.dbf Tnmtdetl.dbf

This description was written to describe the file formats for the writers of pairing programs. In the following paragraphs, there are several suggestions and requests. These are directed to the producers of the pairing programs as requests for items to include in their file generator modules.

It is important to note that Appendix E2 discusses file structure changes being requested for the new program. We will have to create a new TA program with the ability to create the new file structures and get our TDs using it. Only a small portion of our organizers are using the TA program. Most are using pairing programs produced by independent programmers. We will have to let those programmers know about our new file structure and get our organizers / TDs to get the new program. Having the ability to submit reports via the web will be one big selling point to encourage the changeover. As soon as the selected vendor makes the recommendation for the new file format, I will be sending the recommendations to those programmers for comment. The approval or a request for modifications would be made within 7 working days. The selected vendor for our program can leave the code for the new file system to be done later in the process as it may be awhile before anyone can send the new formats.

Comments and additional information

The TA program is designed to be able to submit more then one event in one file set. When this happens, only one each of the Thexport, Tsexport, and Tdexport files are produced and there are multiple header and section records generated. If a report is generated submitting 3 events with the following players:

Event 1 3 sections with 25, 37, & 6 players

Event 2 2 sections with 43 and 128 players

Event 3 1 section with 19 players

The files will be as follows

Thexport 3 records Field 14 in each record will give the record number of the first section in the Tsexport file

Tsexport 6 records Field 11 in each record will give the record number of the first player for that section in the Tdexport file.

Tdexport 258 records.

Data structure ( VERY IMPORTANT ):

In the Tsexport file, field 8, the tournament type is listed. It is very important to understand that this is not reporting what type of event was actually held. It actually indicates what data format is being used for the results in the Tdexport file. CFRATSYS is designed to allow the data entry clerk to enter reports submitted in different formats. The 4 types now supported are Standard Swiss, Cumulative Swiss, Round Robin, and match. The disk input program uses this field to properly interpret the data. If the result format does not match the tournament type, garbage is entered into the Tnmtdetl.dbf file and the event needs to be entered by hand or a new disk requested.

Validation - By TA program

Before exporting the file, the TA program will check several items. This is called validation and is a duplicate of the validation system used by CFRATSYS. This validation should be performed by all programs to insure that the information provided does not have errors that need to be corrected. The program must not create the output file until the major errors are corrected. Any error checking that will help insure that the office will not have to contact the TD is greatly appreciated.

Conceptually, each section is treated as if it were an individual event. The validation should occur on each section. The points that are checked are

Missing ID numbers - Lets submitter know an ID number was not included. Minor

Unmatched Scores - If the report states that 5 won vs 3 and 3 drew vs 5 in round 1, this is an error. Major

Unmatched Opponents – report shows 3 played 5 but 5 played 9 Minor

Duplicate ID numbers – ignore blank fields and report if the same ID number is used more then once. Minor

ID Number format – check proper number of digits and only numeric data is used Major

* Affiliate ID # is included Major

* Chief TD ID # is included Major

* Date formats of MMDDYYYY Major

* Unreasonable dates Minor

Major violations must be corrected before the output file is permitted to be generated.

Minor violations can be ignored but only after the TD is prompted to verify that it is not an error.

Reporting valid cross round pairings is a reason to force the program to ignore the violation.

A duplicate ID can be valid if re-entries were permitted in that tournament.

Missing IDs are valid if player is new or pending.

Incorrect date formats require manual corrections at the office. A date of 03/05/1999 will work, a date of 3/5/1999 will require correction. Please note that I am not sure how the date is actually stored in Dbase format, I am only concerned that our computer gets the correct format. You may have to do some research here or just insure that the input form produces the correct output data.

Unreasonable dates – very old or future dates in either starting or ending date fields, an ending date before the starting date. Have data entry person verify that dates are correct.

The checks with an “*” may better be checked during the data entry process.

Note one minor but irritation problem – the country field. I have to spend about 45 minutes every two months when the rating supplement is produced correcting disk submitted tournaments that have anything other then “USA” as country. This show up in the foreign area of the events rated list. Please prevent this from being anything other then USA unless it actually is a foreign event.

We request that the hard copy crosstable submitted with the event have “new” in the ID field for all players whose ID is not known and whose membership is being submitted with the event; and “pending” for unknown ID numbers when the membership was purchased before the event. The program that creates the report on disk should clear this out and produce a null field so that the ID# format check will work.

File Description thexport.dbf - Header file

Note: Numeric fields are shown as length and # of decimal places 2.0 length = 2 dec = 0

TA Program can create a disk with more then one tournament on a disk. If this occurs, this file will have more then one record. Almost always, this only has one record.

	Field Name	Description	Req.	Field type & Length	Comments
1	H_EVENT_ID	Event number	Y	Char 9	Generated by TA program. yymmddccc: yy - two digit year; mm = (2-char month) dd = (2-char day) ccc =computer generated number
2	H_NAME	Event name	Y	Char 35
3	H_TOT-SECT	Number of sections in tournament		Num 2.0	Generated by TA program. If tournament has two sections, the number in this field will be "2."
4	H_BEG_DATE	Tournament's Start Date	Y	Date 8	MM/DD/YYYY
5	H_END_DATE	Tournament's ending date	Y	Date 8	MM/DD/YYYY
6	H_RCV_DATE	Date USCF received report.		Date 8	Not used by TA
7	H_ENT_DATE	Date USCF rated		Date 8	Not used by TA
8	H_AFF_ID	Affiliate ID.	Y	Char 8
9	H_CITY	City tournament was held.	Y	Char 21
10	H_STATE	Two-letter state abbreviation.	Y	Char 2
11	H_ZIPCODE	Zip code	Y	Char 10	nnnnn or nnnnn-nnnn
	H_COUNTRY	Country for event	O	Char 12	If tournament is held in US, then enter "USA", not "US." The computer sorts events rated by this code. If "US" is entered, the tournament will be listed under "foreign" in the rating supplement's "Events Rated List."
12	H_SENDCROS	Whom to send cross table	Y	Char 1	Values: T - tournament director; A - Affiliate; N - Do not send cross tables.
13	H_SCHOLAST	Is a Scholastic Event	Y	Char 1	Entry: Y - Scholastic Event; N - Non-scholastic event.
14	H_SECREC01	Generated by TA program.	CG	Num 7.0	This field is normally one. It points to the record number of the associated first section file when multiple events are submitted in one file set.

tsexport.dbf - section file

This file will have a record for each section in the tournament.

	Field Name	Description	Req.	Field type & Length	Comments
1	S_EVENT_ID	Event ID		Char 9	Same number as in H_event_id. Computer generated; required.
2	S_SECT_NUM	Section number	Y	Char 2	If tournament has four sections, the program will create four section records. Each record will have a different section number (1 to 4)and each record will have the same s_event_id information.
3	S_SEC_NAME	Section name	O	Char 10	Section name provided by TD/Organizer
4	S_K_FACTOR	"K" factor	Y	Char 1	Valid entries are: F - Full "K" Q - Quick "K"
5	S_R_SYSTEM	Rating system used	Y	Char 1	Valid entries are: R - Regular rating system Q - Quick rating system
6	S_CTD_ID	ID # of Chief TD	O	Char 8
7	S_ATD_ID	ID # of Assistant TD	O	Char 8
8	S_TRN_TYPE	Tournament type	Y	Char 1	Valid entries are: S - Standard Swiss R - Round Robin M - Match C - Cumulative Swiss
9	S_TOT_RNDS	Number of rounds in the section.	Y	Num 2.0	NOTE: If the event is a round-robin, you enter the number of people in the tournament, not the number of games they play. Example, if the tournament is a four- player round robin, you enter "4." For the other tournament types (S, M, C), you enter the actual number of rounds. MAX total number of rounds is 20.
10	S_LST_PAIR		Y	Num 4.0	Number of last pairing number for this section
11	S_DTLREC01	Detail record number	PG	Num 7.0	Record number for first record for this section in Tdexport file. Is = to 1 for first section. Is = to sum of previous sections LST_PAIR + DTL_REC01 for each successive section
12