So why do they call it FW1 for women's advanced?

Men's advanced is MA1, so women's should be FA1 or WA1 but not FW1

MA1 stands for Men's amateur 1, right? Maybe Male amateur 1? So the women's counterpart would be either WA1 for women or FA1 for female.

But FW1 stands for female women 1, makes no sense. How many other types of women are there than female women?

There is an FA1 available but no Am Women have ratings above 914... (just kidding). Not sure why it happened but once it got coded in the database a while back, changing it would apparently be a problem.

I pointed this out when the div-codes changed from M1O/M1M...MPO/MP....F1O/F1M.....FPO/FPM... and there was some explanation that I dind't really buy. :)

It was a lot easier under the old system because the first character was "gender", the second was "class" (P=pro, 1=Adv, 2=Int, etc) and the third was "age protection" (O=open, M=masters, G=grands, etc). It was the same for all divisions so automating stuff was simpler.

It's harder now because the second digit is either pro/am class or am age protection and the third is either am class or pro age protection.

the reason is that the database that runs the whole thing was incorrectly constructed, making any changes very difficult. it also meant that some obvious division abbreviations were not able to be used. overall, it is risky to use concatenations to contain a meaning. rhett's examples about the confusion with sometimes the first letter meaning one thing and other times it means another is the poster child for this kind of snafu.

the reason is that the database that runs the whole thing was incorrectly constructed, making any changes very difficult. it also meant that some obvious division abbreviations were not able to be used. overall, it is risky to use concatenations to contain a meaning. rhett's examples about the confusion with sometimes the first letter meaning one thing and other times it means another is the poster child for this kind of snafu.



well with you being on the bod now and everyone not really having any titles...is it something that can reasonably be fixed or does the whole pdga database have to be rewritten??

you have professed to be a web genius....let's see some action :D:D

keith

Between fixing something that affects no one, like the letter code designations for the women's divisions, versus fixing something that affects all of us, like the 1000 mile wide zones of exclusion for tournaments that need them the least, let us hope they pour their resources into the letter code designations. :D

keith, it would be seriously major rewrite

fixing a database schema is a one-man project that needs very little outside input and can be done fairly quickly. re-organizing the structure of tournament distribution is a much different task. As silly as it is, whenever fixing something small comes up, someone always says "why fix that when there are much bigger issues?" As if one would in any way affect the other.

I've offered to help before... I mean this sort of thing *is* how I've made a (somewhat decent) living my entire professional career... but the PDGA has yet to take me up on my offer.

Oh, and I've not seen the schema... but the rewrite can't be that serious. I guarantee I've seen worse ;)

I don't believe it's just one database because that code may have come from the previous database to retain backwards compatibility.

youre right fixing the db would be pretty simple. but the code that hits the db would be totally broken so the apps wouldnt work. starting from scratch might take less time. theo is the one who can grant access. have you emailed him directly?

I'm not sure I buy the legacy database explanation since the div-codes were good the way they were and then got changed to the current versions. This all happened around 1999, plus but not minus a year or two.

I haven't emailed theo directly, but I've been basically "discouraged" from doing so by others within the PDGA who feel that it is a waste of time. Someone shoot me a PM with his info, or post it or whatever and I'll give it a shot.

The last time I asked about this was in conjunction with my upcoming rewrite of titledisc.com, but since Ben and I have both been busy lately that is on hold. If I could get the PDGA database a little bit more functional, perhaps they would let me query it for things like putting limits on what divisions a player can sign up for and automatic players list updates for sanctioned events, who knows what else... now that would be cool. A fixed schema would benefit a lot more than just me, though :)

I'll try to explain, but I'm not going to get into all the gnarly details, as it's not going to change the current situation (and I've have to dig up some notes to do it).

When I joined the PDGA Board in 2002, I took over IT. I am a trained and skilled software engineer and architect. In my "real life", I am a senior Enterprise Architect for Portland General Electric, with technology architecture responsibility for the whole enterprise (3000 employees, 750000 customers), in case you want credentials.

The PDGA database in 2002 consisted of an old DOS DBase (Clipper, actually) database application, which the PDGA didn't retain source code for. All of the division codes were hard-coded into the application. In order for us to add codes, I had to figure out a design that would be backwards compatible, yet could be implemented by patching a binary with some new codes, where I had to work within a few slots in a fixed-length table. It was a significant engineering challenge.

In addition, I had to deal with the fact that the software made assumptions about the values in the second and third positions of the code.

The bottom line is that I had to make some compromises in consistency in the coding scheme. I was well aware of it at the time, and I worked with Brian Hoeniger to minimize the inconsistencies as much as possible, while allowing us to move ahead with a new division structure.

Yes, as Pat mentioned, it would have been better to rewrite it from scratch. That wasn't feasible at the time, and we weren't going to hold up the implementation of ratings and the new divisional structure until we could rewrite the PDGA's database processing applications.

We are 80% through a rewrite of the old DOS code into the latest version of Microsoft Access, a well-supported office application environment that will be around for a long time. The new application has interfaces to the web site database, which we use regularly for the tournament schedule, results, ratings and membership database.

We are always looking for skilled, motivated software engineers to help out. If there are folks out there that have volunteered and not been followed up with, that's probably my fault. With my new job and a family illness and death last year, my focus on PDGA IT hasn't been what it was a few years ago. I have been working with the staff to transition the IT project management responsibility, and the management of volunteers to staff. I had a Microsoft Access programmer all set up, with the code for the backoffice application, and almost a year later, he decided that he really wasn't going to be able to help out. That's not unusual when dealing with volunteers, but it leads to long delays in getting certain projects done.

David Gentry will be the person in charge of IT in the future, but the transition will happen gradually, as we bring more staff resources in. This process is being slowed down now due to the major staff transition we're undertaking in 2007 (Brian and Lorrie leaving).

If you have any specific questions or concerns that I can address, feel free to send me a PM. I will respond quickly with answers.

Theo Pozzy
PDGA Commissioner

I'm willing to help out, but I can't say that I condone the use of Microsoft Access for an application like this. If you want to use something very much standard that will be around forever (and is microsoft since it seems like the PDGA likes microsoft), then I'd go with SQL server. If you don't want to pay for that... mysql is free in most cases, cheap in the rest, and is just as powerful.

Architecture recommendations aside, I see no reason why the software you are referring to can't be re-written in a relatively short timeframe for a relatively low cost. There may be a lot of little programs running around in there, but they can't be *that* extensive. I agree with the idea of getting this stuff into a more solid architecture, even if it's not the one I'd choose. I will be happy to help out. I'll send you a PM with my contact info in a few.