I have my own program for reporting results.
The big problem is that DBF files are now so obsolete that the latest systems (MS ACCESS) no longer support exporting tables to DBF format.
It is annoying to have to revert to an older system in order to report results.
Then to decide whether to switch back (and forth) to a modern system or be stuck in olden times.
The TD report page hasn’t updated its statement about a “2015 new system option”.
Hopefully, it will be beyond DBF.
I recall there being an HTML option mentioned a while back, but can’t find it.
The proposal is XML, but I have no idea where it stands. Doesn’t Access still include an ODBC driver for “xBase”?
Frankly, I’d prefer JSON. XML is redundant, verbose, and redundant.
Isn’t it merely verbose and redundant? The first tag is necessary in JSON as well—it’s the closing tag that makes for the fat files.
One problem that I see with any “text-based” submission format is the well-meaning TD trying to do an ex post hand-edit fix on the file generated by the pairing program and making a mess of it. (Run one of those through Word and you have no idea what’s going to come out).
Wouldn’t surprise me one bit.
Still, something this century would be nice. Is there someplace the current format is documented?
(BTW, just upgraded from WinTD 4.11 a few minutes ago.)
The “2c” spec is posted at
Thanks.
Tom, thanks for mentioning Access ODBC; I should have thought of that since I used it 16 years ago on a Y2K project for another legacy db system of which I also had no source copy.
I jumped right into Access/ODBC and sure enough, dBase was advertised.
After a few clicks and such I got to… (dbf table) “not saved”.
After a few clicks on “help”, I got to… (your only hope for) "that info is now in MSDN, want to buy a subscription?’
Success is imminent.
There are several paths forward.
I might take more than one just to have a better base for future projects.
I once looked at one of the USCF *.DBF files with a DEBUG-type program (hex display of the file contents, byte by byte), and was able to figure out enough of what was going on to be able to fudge things satisfactorily.
I might even have posted the details somewhere on these forums, several years ago.
Bill Smythe
Why would one reverse engineer something when the specs are published?
The published USCF specs are based on dBase, with field names etc. and no raw displacements.
If one doesn’t have a system that knows dBase, one could still deal with the .dbf files which are impure text files.
It isn’t hard to figure out where everything is as displacements in those files; just a little tedious and a little risky.
Because I’m a reverse-engineering sort of guy. Also because published specs are often vague and poorly written, forcing one to look at a sample file to understand what was actually meant.
Bill Smythe
Just came across this in the TD/A area:
April 2016 Gold Master in JSON form
Looks good. I especially like that the player names are not truncated like they are in the DBase and tab delimited files. It’s also easy to add additional fields as time goes along.
Quick question: What do all of the extra characters in the rating field represent? I’m guessing the plain asterisk is for established rating and the /xx is for provisional number. What do the letter codes mean - such as *B0,*B5,*A0, etc.?
Some interesting fields that could be added:
Gender (unless that runs afoul of privacy concerns)
FIDE Title
USCF Title
Hopefully you’ll keep creating these files. I can use these over the older files at least for the expanded player names if nothing else.
The *B0 is the title information. If I remember correctly, it’s current title and norms to the next one up.
(I remembered correctly, but that’s apparently the old (i.e. dead) title system information).
This is an experimental file, if it goes into production obsolete information such as the title data left over from the 1990’s should be deleted.