On 2009 Jul 4, at 2:33, Lee wrote:
Steve,
In my case the same script has been used in, probably, a 100 or
more solutions but only on a couple of occasions has this problem
occurred. In this latest case, the client had just updated to new
PC computers running Vista (last week). He has been running the
same program for a couple of years without this intermittent
problem. It started just a couple of days after using the new
computers. I will go back and alter the script lines to 'Set field'
rather than using the copy and paste option (same layout). There
are no locked records either. Last Wednesday I placed a 'pause
script' for 1 sec immediately before the copy command and there
hasn't been a problem since. This is how I overcame it when it
first occurred some years ago on XP.
Hopefully the Set Field will change this potential issue.
We're all stuck with trouble-shooting from time to time, and it can
be maddening. The biggest pitfall is when you're looking at your own
work, trying to figure out what went wrong. Everything LOOKS just
fine. (Well, it should. That's why you put it there in the 1st
place.) But what it really is is not "fine" but "familiar", therefore
"comfortable". Sometimes going away, doing something entirely
different, then coming back later and looking at it with fresh eyes
will make the error pop out at you where it hadn't before.
Better than that is getting someone else (guaranteed to have a fresh
set of eyes) to review your work for you. That's why, whenever any of
the non-profit groups I work for gets a new staff person (something
that happens with distressing regularity in the chronically
underfunded world of non-profits), I gush all over how valuable this
person will be to the database, because he or she will be able to
view it fresh, without preconceived ideas or the workarounds that all
the veterans have long since taken for granted. "Take notes!" I
enthuse. "If something seems odd, or poorly explained, or more work
than it should be, or counter-intuitive, WRITE IT DOWN. Keep a
notepad handy for that very purpose. Nobody else here is as valuable
as YOU are in trouble-shooting this program." Yes, I make a big fuss
over it, because that way they'll actually DO it. And the feedback is
invaluable.
The most memorable trouble-shooting job I ever had was when I was
serving as a TA for a computer-programming course back in the Dark
Ages. One student came to me with a printout of what looked like a
perfectly workable program that just wasn't doing the job, and he
couldn't figure out why. Neither could I. Finally, after half an hour
of progressive frustration, I tried something desperate. I went down
the hall to the physics lab and got a magnifying glass. I said "We're
gonna look this program over line by line, word by word, up close and
personal, until we find the problem." Sounds nuts, right? But it gave
a certain rigor to the examination, a certain distancing from the
gestalt, as we ignored the forest and looked at each tree
individually. And that's how we found the word where he'd typed "0"
instead of "O".
Whenever you're working with electronics and something goes haywire,
the standard trouble-shooting technique is to swap out the components
in the chain, 1 at a time, until the problem goes away, then look
more closely at whatever you just took out, because that's probably
where the fault lies.
In logic, there's a well known fallacy called "post hoc ergo propter
hoc" (Latin for "after that, therefore because of that"). This is the
fallacy that gives rise to most superstitious behavior. For instance,
a pigeon is pecking randomly around the inside of a cage when the
daily feeding arrives down a tube. In the tiny little pigeon brain,
whatever it was pecking at before the food arrived was what MADE the
food arrive. So, next time the pigeon's hungry, it goes over and
pecks at that thing again. Nothing happens the 1st 20 times or so,
but eventually the food arrives again, and the behavior is
reinforced. A superstition is born.
Now, while "post hoc ergo propter hoc" is a fallacy in LOGIC (where
you're looking for absolute reliability, a la syllogisms), it's
actually a pretty good way to go when trouble-shooting, where you're
looking for probability, not certainty. Something (like a database
script) isn't doing what it used to do? Well, what else have you
changed recently? At the very least, that's a good place to begin
looking for the CAUSE of the changed behavior. That's exactly what
Lee did here, and the thing that sprang most readily to his mind was
a transition in operating systems.
But perhaps that wasn't the ONLY thing that changed. Which leads to a
fallacy of a different sort, the "correlation-causation" fallacy.
Scientists and statisticians are constantly warned (and about half
the time actually remember) that "correlation is not causation". The
reason it's so hard to keep this in mind is that you can't have
causation WITHOUT correlation. That is, correlation is a NECESSARY
condition to demonstrate causation; it just isn't SUFFICIENT to do so.
An example leaps to mind from a beginning stat class. We were given 2
data sets — (1) per-capita milk consumption and (2) death rate due to
cancer — for about 150 countries (fewer of them then) and told to run
a Pearson's correlation coefficient for them. It turned out to be
pretty impressive, something like 0.65, which meant that they were
strongly positively correlated. As one went up, so did the other; as
either went down, so did the other. "What can we learn from this?"
the instructor asked. Naturally, somebody in class (not me, I'm
relieved to recall) went with the obvious: "Drinking milk causes
cancer?".
No, as it turns out, that's a false shortcut across the canyon. What
you have to do is walk back up the trail until you come to a point of
common ancestry from which the 2 trails diverge, 1 going down each
side of the canyon. In my stat-class example, that point of common
ancestry is economic prosperity. If a society is well off, it can
afford the livestock infrastructure that enables many of its people
to drink milk well past infancy. A prosperous society can also afford
the sort of medical care that enables many of its people to live well
into old age. And cancer is predominantly a disease of the elderly.
So I try to recall that, whenever B and C have happened fairly close
together and C is bad, it's not necessarily B's fault. It might be a
shared ancestor (A). Or even just a coincidence. But, as a practical
matter, B's a good place to start looking; just don't get fixated on it.
Finally, there's the matter of trouble-shooting computer hardware.
Here I take a totally pragmatic approach. Restart. If it solves the
problem, I don't particularly CARE what caused it. Chalk it up to
cosmic rays or something. Short of being able to rerun reality, I'll
never know, so I don't fret over it.
