The best I could find is draft version 1C (2006?).
Could you make version 2C easier to find?
Within that 1C version appears in the tdexport definition:
D_RNDnn * The number of round results fields must match the number of rounds in S_TOT_RNDS for this section.
If not fixed in version 2C, does this mean:
(a) fields beyond nn (rounds this section) in this chunk (belongs to this section) may exist but must all be BLANK;
Or (b) All sections of a tourney must have the same number of rounds, i.e., if different submit as > 1 tourneys.
The version 1 files (defined around 1990) must have exactly 10 rounds per record. For events with more than 10 rounds, there is a field that distinguishes whether a record is for rounds 1-10 or 11-20.
Unless they’ve changed recently, neither WinTD nor SwisSys supports 20 round events, they max out somewhere around 14 rounds, so the upload protocol for both the old and the new DBF file structures has probably never been tested with an event of 21 or more rounds.
The internal record structure supports events up to 32 rounds (an arbitrary limit), but the largest event entered since 1991 appears to be a 24 round event, so that limit doesn’t seem unreasonable.
The draft version 2C of the revised DBF file format is available at
secure2.uschess.org/TD_Affil/fileformat.php
The 1C in the header was a typo that has been corrected, that file is version 2C.
This draft format was never officially released, but it was implemented by WinTD anyway. We chose to support it with the new programming, because it was one way to start collecting color information, at least from TDs who have a recent version of WinTD. (If uploaded or entered online, color information does show on MSA, incidentally.)
The rounds issue is one of the reasons that format was never finalized. What WinTD appears to do is look at all sections in an event and use the maximum of the number of rounds to determine the size of the detail file. Since there is a ‘number of rounds’ field in the section file, any surplus fields for a section are ignored, just like they were for the old version 1 format with its fixed 10 rounds.
The XML draft standard that was posted several years ago is no longer current and will not be supported, though a new standard, probably also XML based, should be available and supported later this year.
Thanks! Very prompt and informative response, as usual.
There were a few other minor issues I can now check out.
You should know that I wrote my own program (worked fine with version 1 for 5+ years); did not use one of those canned ones.
In addition to the real tourney I’m reporting this week, I’d be happy to generate a “stress test” one with over 20 rounds (and bail at the last minute), if you wish.
I’m sure you see the idea: if your receiving program matches those sending programs, but do not match the written specs, I’ll probably run into the issues.
Having more than 2 beta testers is good.
The plan for the XML parser is to start by writing a program that can take an existing event and write a properly formattted XML file for it. That way previously rated events become part of the beta testing process and provide us with examples to show developers.
The webpage suggests that one not bother now to implement the new 2C dBase format, but instead wait for XML in 2012.
Also that the old “1” dBase format will crease 3/1/2012 (had been 2/15/2012) and that the new XML is not yet available.
Can one assume that there will never come a time when neither dBase “1” nor XML are available?
It’s also unclear if Tab delimited 2C is available right now.
There doesn’t seem to be a box for it, and I wouldn’t want to place such a file in the dBase file boxes just to see what happens.
It says no such thing.
The 2C format now says:
Elsewhere it says that the old ONLINE ENTRY web form will no longer be available for new events and that TDs who have in-progress events using it should finish working on them by March 1st.
Both version 1 and version 2C of the DBF upload format will continue to be supported, most likely for many years, because TDs have many different versions of the pairing programs, including some home-grown ones, and requiring them to all update to newer versions, when ones are available that support a newer format, would not be very popular.
A problem with the 2C format is that it, like the original format, does not include all the fields we currently use. 2C’s main advantage over version 1 (and the only reason we decided to support a draft format standard) is that it includes a few fields like color information and time control that version 1 does not include. But there are also fields it does NOT include, like multiple time controls for events by round, participant coding and additional TD information, and there are fields we will not be supporting, like reporting results for double round robin events. We also no longer need the rating system field, because the time control information unambiguously determines the rating system.
There was never a tab-delimited version of 2C published, even in draft format.
It seems appropriate, then, to suggest to PROSPECTIVE developers that they wait for a more updated format.
OK, thanks for the clarification.
Off-line (batch) developer/TDs should use whatever (usually “1”) DBF version they have for as long as it takes (ASAP of course) to convert to the (not quite yet ready) 2012 XML standard.
On-line TDs transition ASAP, certainly before 3/1/12.
While this is true, a ‘rating system’ field will probably be in the XML standard anyway, because we can never predict what the Delegates may do with time controls in the future.
Currently the time control unambiguously specifies the rating system, but that may not always be the case.
As long as it remains true, any rating system information included in an upload file will be ignored (or possibly raise an error if it is inconsistent with the time control information being reported.)
I just did my very first submission with the new format. It took about the same amount of time as before. The cross-table/wallchart is easier to read now.
I’ll wait to see how it looks in MSA.
Edit:
main.uschess.org/assets/msa_joom … 1201286852
Looks good
I also just used the new format for the first time. I had a few issues but some of it was just me. We had two sections with different time controls so I initially entered both of them per the examples with and inbetween. But this was an easy enough to fix by then editing the sections. I liked the fact that I was able to go ahead and actually purchase the 3 month membership for a player when I went to get him his USCF ID number. The program caught an instance of a player who I had transposed a 7 to a 4 and actually had the wrong ID #. It was weird because I’m looking at the name being shown and saying to myself I don’t even remember him being there.
But after looking up the player that should have been listed and correcting the ID everything worked from that.
I thought one out of the two warnings of a player playing above their rating was a bit strange. Then maybe because I’m just tired I must have entered my Visa card number inaccurately. But that was easy enough to fix too.
In the new format if you discover that you have missed renewing a membership and are offered the 3 month option can you go back to the membership module and renew that individual for the full year and then come back and do a Refresh and have that reflected on page? (obviously after the update is show in the MSA area)
The problem with just doing a ‘refresh’ is that it mostly just refreshes and checks the information you have typed in (like results you’ve typed in), which may or may not take into account all external updates. It is safer to exit the data entry program, do the membership batch and then bring the event back up, because that forces a complete reload of the data. You will probably need to do another validation as well.
Good. That’s what I wanted to know.
Thanks
I find it odd that I received a warning for a player playing above his strength when they lost three games and received a 1 point bye.
Without specifics, there’s no way to check on that.
Validation Report for event 201202134622
LASTCHANCE
0 errors
1 warnings, corrections or overrides will be required
**Warning section 1 Possible ID Error pairing # 12 ID 12412381 Factors:
Rating, Strong Performance
0 alerts
Detailed Validation Report Follows:
Validation Report 2012-02-14 10:02:01
Status 0 errors, 1 warnings
Event ID 201202134622
Name LASTCHANCE
File Name lastchance2012
Event Dates 2012-01-23 - 2012-02-13
Affiliate ID A5010322
GREATER PEORIA CHESS FED
Chief TD 12483626
RONALD J SUAREZ
Submitted By 11315844
R WAYNE ZIMMERLE
City PEORIA
State IL
ZIP 61604
TLA None
Total Ratable Games 18
Rating Fee $4.50
Section 1
Section Name LASTCHANCE
Section Dates 2012-01-23 - 2012-02-13
Section Chief TD 12483626
RONALD J SUAREZ
Section Chief Assistant11315844
R WAYNE ZIMMERLE
Rounds 4
Players 12
Ratable Games 18
Time Control G/75;d5
Rating System Regular Rated Only
Participant Coding Adult/Open (Non-Scholastic) Event
Section Type Swiss
**Warning section 1 Possible ID Error pairing # 12 ID 12412381 Factors:
Rating, Strong Performance
Full Error Recap
**Warning section 1 Possible ID Error pairing # 12 ID 12412381 Factors:
Rating, Strong Performance
The validation program uses a simplified version of the old performance rating formula when looking for possible ID issues, providing the player had at least 3 rated games.
That player has a rating of 555, all of his opponents have a rating of 1600 or higher. That’s going to come up with a performance rating of over 1200 based on the old ‘+/- 400’ formula.
(This is a good example of what’s wrong with performance ratings, incidentally, which is why they are not shown on the crosstable and their use is mostly deprecated by the USCF. A revised version of that formula is used when computing someone’s provisional rating for their first 8 games, or if the player has all wins or all losses.)
Did the old warning of “Player rated below most other players” or whatever go away? It seems like that would be more (or at least equally) appropriate in this case.
Alex Relyea
Perhaps a better (or additional) way to check for wrong IDs would be to compare names. Since an exact match cannot always be expected (different spellings, omitted initials, etc), maybe just the first three characters or so should be compared.
Bill Smythe
Names aren’t included in the old upload files, and I’m not sure if they are in the new-style files either.
A better way is for the TD to check manually that the records match, but I bet all TDs won’t do that.
Alex Relyea