Just from my experience today, not only must the database be there, one way
or the other, and indexes computed, etc., but one must go through and
manually check for those who did not work...or who did not even sign up to
work (there was one of those this time). Plus, the classes change, as many
moved from one class to another. They also change car numbers, cars, and all
this would have to be double checked. Some even move and change addresses.
That stuff is easier to do at home without interruption. I tried an on the
fly on my laptop a year or so ago, and found myself missing out on all the
fun. Anyway the keyboard stinks.
--Pat K
----------
>From: "Mark J. Andy" <marka@telerama.com>
>To: Bay_Area_Autocross_List <ba-autox@autox.team.net>
>Subject: Re: Preregistration and computerized timing/scoring
>Date: Mon, Nov 5, 2001, 5:54 PM
>
>Howdy,
>
>On Mon, 5 Nov 2001, Jerry Mouton wrote:
>> How many entrants run at a typical event in your local
>> region, Mark?
>
>4.
>
>:-)
>
>Ok, seriously... Around 100. But we run registration and the event a
>little differently. Registration opens at 8am and closes at 10am, so
>we're pumping 100 people through in 2 hours. With the longer time that
>you folks have registration open, I think you'd have a similar # of
>registerents per hour. Again, the computer entry portion doesn't seem to
>be the longest thing you do during registration, so it doesn't add any
>real time to the registration process for the event (of course, it does
>add 30 seconds to each individual's time, but since it happens in parallel
>to the rest, it doesn't affect throughput).
>
>> Again, who would do all this in SFR? Is registration data entry a signup
>> work assignment? Or is there someone who is there at every event
>> early in the morning, dedicated to make this work?
>
>In our case, I think there's a chief of the computer type guy who does it.
>However, its not like data entry can't be taught. No reason it couldn't
>be a work assignment.
>
>> Who would you see handling the merge of databases? Is your
>> experience of database merge that it typically just runs, no problem?
>
>Sure! You mean that database merging is ever an issue? :-) (I work as an
>MIS-type during the day...)
>
>I really think you could do it on one system. If you couldn't, two would
>easily be enough. With only two databases, the merge is relatively easy.
>You'd obviously need to have a couple things to make it work well. #1
>would be a t&s program that could either handle doing a merge (unlikely)
>or that talks to a database that can facilitate doing a merge (pretty
>likely). #2 would be someone to setup a merge program that would toss out
>duplicates for manual intervention and/or someone to run the merge.
>
>Given where you guys run, I find it pretty hard to believe that you
>wouldn't have geeks jump all over each other for the easy work assignment
>:-)
>
>> the several. Of course, SFR might have an easier time, but again, we'd
>> be under extreme time pressure, and the event would depend on
>> completion of the merge in the 10 minutes between start of the
>> drivers' meeting and beginning of run group 1 -- without failure.
>
>There's no reason you can't close registration for the morning run groups
>a half hour before the driver's meeting, but what you're saying makes
>perfect sense. Certainly at the beginning of something like this, you'd
>need to run a paper system like you do now as a backup at an absolute
>minimum.
>
>> And, online database update continuously during the day as new people
>> showed up and registered.
>
>This would be more "interesting" :-)
>
>My recommendation would be to use one computer, close registration for
>morning run groups, hand that database over, then capture afternoon run
>groups to a different database. I.e. each database sees "registration"
>and then "timing" in that order. If you wanna complicate my life and
>allow either group to register in the morning, keep seperate database
>starting at the beginning.
>
>> Sounds a lot tougher to me than it does to you!
>
>My post was only to indicate that plenty of people do it, not that you
>should. SFR should decide what makes sense to them and then run with it.
>As you folks are fond of saying, you're the biggest region in the country
>and sometimes need to work a little differently than everyone else.
>
>It does seem like computerizing earlier would make getting data back to
>the web a fair amount easier, calculating pax classes on the fly, etc.
>
>Not trying to stir up trouble. Just pointing out what I've seen other
>folks do.
>
>Mark
|