[AccessD] More hi-jinks

[aclawhon at hiwaay.net]

Susan:

Look at these "hi-jinks" this way.  You probably wound up with this  
"simple" database problem because somebody on the [paid] full time IT  
staff with the State of Kentucky was assigned the task, spent a little  
time going around in circles and then gave up reporting back to their  
[incompetent] bosses that what they wanted "... couldn't be done" and  
that was that.

I was in a similar situation back around 1995.  My boss at that time  
(Mr. Montgomery) asked me if I could "take a look" at a problem he  
had.  About all the information he gave me was that it involved a  
"database" and I would have to use a database software package called  
dBASE III-Plus.  That was it.

So I started working on this "little problem" Saturday morning around  
7:00 A.M. - while very few people were around and I could think - and  
got my initial results around 4:00 A.M. Monday morning.  (Somewhere in  
that 38+ hour death march I dozed off and slept for maybe four hours.)

I never will forget this for as long as I live.  Mr. Montgomery came  
in around 7:00 o'clock Monday morning (his usual starting time) so I  
told him: "Mr. Montgomery, I've got something I want to show you."  I  
then demoed the (inelegant but working) "solution" I had cobbled  
together.  Mr. Montgomery was a true engineer - he (very rarely)  
showed emotion.  However, on this occasion, I saw just the hint of a  
smile play across his face.  (That's about as close as he gets to a  
compliment.)  So I tell Mr. Montgomery I'm exhausted and I'm going  
home to get some sleep.

The next morning (Tuesday morning) when I got to work, Mr. Montgomery  
called me into his office and informed me that I was being promoted to  
"programmer" effective immediately.  Turns out that Pat Green, one of  
the ladies I worked with who just happened to be working that weekend,  
told Mr. Montgomery that "Alan had been working on that computer all  
weekend."  Mr. Montgomery then went over to the main office building  
to see the General Manager, Dr. Pastrick, to plead on my behalf that I  
be promoted.  Dr. Pastrick agreed and my pay and compensation  
immediately tripled.

There was a funny backlash to my promotion.  Turns out I was the  
fourth "programmer" Mr. Montgomery had approached with the problem.   
Of the two (previous) programmers who Mr. Montgomery has asked to  
solve the problem, one tried (and gave up) after about a week.  The  
second programmer wouldn't even try.  Finally, out of desperation, Mr.  
Montgomery asked a "Senior Systems Analyst" if he could find a  
solution?  The SSA reported back that the problem was "impossible" to  
solve.  It was at that point that Mr. Montgomery decided to take a  
chance with Alan.  (Of course, Mr. M didn't tell me that the problem  
was "impossible" to solve.  Ha! Ha!)

So I taught myself dBASE in 36 hours.  (I had a pretty good idea of  
how to solve the problem right from the start - it was mostly a case  
of looking up the right dBASE commands to get the job done.)  Once I  
was promoted, the two "programmers" and the Senior Systems Analyst  
didn't take it too well.  In fact, during a Christmas party in the  
main building. one of the programmers pulled Dr. Pastrick off into a  
hall office and actually tried to make a case [to Dr. Pastrick] that I  
should be fired.  (I just happened to be walking down the hall at the  
time and heard this woman talking to Dr. Pastrick from right outside  
the door!)  I called Mr. Montgomery that night and told him what I had  
overheard.  He told me: "Alan, you just do your job and don't worry  
about it."

So how does all this apply to you and Salato?  Susan, you should look  
at this as an opportunity to excel!  Solve this problem and you could  
wind up getting promoted into a full time state job (with full  
benefits) and all that.  Heck, if there are other Salato offices  
spread around the state, and your software is really good, you could  
wind up with a big promotion as you will be seen as indispensable -  
your solution could wind up being used in every single Salato  
location.  Susan Harkins of Frankfurt, Kentucky will suddenly be a  
programming superstar!  (You'll be Wonder Woman!)

Just think: This is not an unsolvable problem - this is an opportunity  
to excel!  Plus you have a crack team of free "consultants" to help  
you.  (that would be us ...)  :-))

Been There, Done That Alan of Huntsville



Quoting FW Salato Center <Salato at ky.gov>:

> Just when I thought I had this thing mastered - I will never  
> volunteer to write another simple database. ;)
>
> I think you all know the main problem - the distinction between  
> individuals and species tasks. With the medical/vaccine, I provided  
> a second form for species and used a Recordset to update all animals  
> of the same species when tested, vaccinated, and so on. The form  
> displays a list of individuals in that species and the user can  
> remove an individual. We can also update an individual within that  
> species as necessary, and it often is. We have one bison cow that  
> receives a lot of specialized care that the others don't need.
>
> New complication - food. We've just started working on the food  
> structure - the longer I chew, the bigger it grows. :(
>
> Food for the individual animals is easy to track - amount in, amount  
> removed from previous feeding. These animals are all fed as  
> individuals.
>
> We have several species that are fed as a group. There's no way to  
> divvy up that feed by individual, so the medical/vaccine solution or  
> specifying a vaccine or treatment and updating all of the animals in  
> that species doesn't work. I can't update each individual because  
> there's no way to track how much each individual ate on a given day,  
> if any at all. The herd or flock is fed and I can track the herd,  
> but there is no "herd" or "flock" entity for these species. They're  
> all identified as individuals, because we need them ided that way.  
> As I mentioned before, we have a bison cow that needs medical care  
> that none of the others do (and she often does). They need  
> individual status.
>
> I'm seriously considering just throwing in an entity called "deer  
> stock," "bison stock," "turkey stock" - and so on. Perhaps I need a  
> second table of herd/flock types and then I can always use a UNION  
> when I need to combine individuals and groups for some reason. That  
> probably complicates date entry - but I'm using multiple data entry  
> forms for individual/stock conflicts, so that's not really all that  
> new.
>
> I just have no idea where this is going to lead at the moment.
>
> I should be home knitting and dividing flowers in my yard.
>
> Susan H.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>