Some javascript/style in this post has been disabled (
why?)
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.
