George,

Now that you've had the opportunity to bask in the glory for a few days I'd like to make a few comments about this epistle. They are interspersed between your paragraphs/sentences.

>Dear All,
>
>During my period of time here on the UT, and with the VFP community in general, I’ve attempted to live up to a simple credo, or set of rules. These are:
>
>1. I tell people when I know the answer.
>2. I tell them when I’m guessing,
>3. When proven wrong, I'll admit my mistake and apologize.

While it obviously wouldn't be a part of your "credo", let me add one:
4. To get antagonistic/personal/nasty with a specific few individuals.
>
>I think that, over the last five years here, I’ve done a reasonable job of living up to that credo. Have I not at times? Perhaps so, but I am human, with my own set of foibles. I’m reminded here of a quote
>
>“Every man is as heaven made him, and sometimes a good deal worse.” – Cervantes
>
>I believe that, in general, I have lived up to the credo expressed above. Others may take issue with this.

In the general case you have lived up to it nicely, but in a few individuals' cases you simply forget the whole "credo" every time you choose to reply to them. To those people your "credo" doesn't exist.

>
>The thing I believe about programming is that it is a combination of art and science. Art in the fact that by definition it’s the conscience use of skill or knowledge in the creation of something. Science, by the fact that it utilizes the theoretical in proper design, and demands that we prove any algorithm we create.
>
>The latter is an important point, Basically, what it says is that we are scientists. As such, we should be required to adhere to the scientific method. I like to sum this up in a series of steps.
>
>1. Realization – This is the point where we realize what the problem is that we have to solve, or realize that something doesn’t work as we thought it would. Here, we form the hypothesis as to why this occurred.
>2. Confirmation – We determine, either through someone else or another application, whether or not the problem has been solve, or, in the case of a bug, still exits.
>3. Explanation – We document why something works, or form a hypothesis as to why it doesn’t. In the latter case, this takes us back to step one.

These are fine except that only the MS VFP Team is in a position to "explain" those things that remain in the apparent state of not working as expected so when the "explanation" step has such a conclusion then "back to step one" is not really an option with "bugs".

>
>I believe that the three most important words in science are, “I don’t know” since they are the starting point to acquiring new knowledge. A good scientist, however, must have an open mind and when multiple plausible and reasonable explanations exist will not take one over the other by calling one factual.
>
>Recently, there has been much discussion on the subject of bugs. First, of course, we must define what a “bug” really is. Therefore, for purposes of definition, I will define it this was: A command or function that doesn’t work as anticipated. Now there are two plausible and reasonable explanations for a “bug”. It is unintentional or it is intentional and by design.
>
>Regardless of the circumstances, every time such is encountered, as good scientists, we should have an open mind to the issue in order to properly determine whether or not it is, indeed, a bug. If a plausible and reasonable explanation exists, however, the best we can say is, “I don’t know”.
>
>Let’s take a recent example. The behavior of VFP in regards to division by zero changed between versions 6.0 and 7.0. Some feel that this is a bug; others believe that it isn’t and may be by design. The situation arises because of checking for numeric overflow. For example, consider the following snippet:

CREATE CURSOR Foo (Foo N(2))
>APPEND BLANK
>REPLACE Foo.Foo WITH 100 && Numeric overflow occurs.
>APPEND BLANK
>REPLACE Foo.Foo WITH 1 / 0 && Numeric overflow occurs.

s A common check for numeric overflow is to compare the field value against division by zero. However, as the above shows, division by zero isn’t the only cause of numeric overflow.
>
>Is there a reasonable and plausible explanation for this change in behavior? Certainly, but before getting to that consider that VFP is one of the few languages that doesn’t consider it to be an error. I began working with Fox in FoxBASE+ 2.10. When I initially started, I was surprised that division by zero didn’t throw an error. Based on my recollection, I don’t recall ever seeing an explanation of this. I may be wrong about this but that’s my recollection.
>
>Now in checking for numeric overflow, it is a common practice to use an expression like: Alias.Fieldname = 1 / 0. However, strictly, this isn’t always true. For example, in the above snippet, the value in the first record clearly isn’t equal to the value in the second. While it may have been that in versions of FoxPro prior to 7.0 this would return true regardless of the cause of the overflow, 7.0 considers division by zero clearly differently than its predecessors.
>
>Mathematically speaking, division by zero results in an unknown. In many ways, but not all it is very similar to a null. With a null the expression: .NULL. = .NULL. returns false because it cannot be evaluated. Similarly, 1 / 0 = 1 / 0 returns false in 7.0 (but true in previous versions). It makes sense that the preceding statement returns false for the exact same reason that comparing a null to itself returns false. The statement can’t be evaluated and therefore cannot be equal to anything.
>
>Further, it should be considered that the printer drivers from both HP and Lexmark, contrary to DDK specifications, leave the state of the FPU in a way that they expect that the calling software handle exceptions. This led to problems with 6.0 prior to SP3 because of fault tolerance. While many of these errors have been resolved. There are still some cases where using the reports to either print to a preview mode or to the printer, cause errors.
>
>Is it plausible and reasonable to think that this change in behavior was implemented to circumvent these problems? I believe so. Yet certain people believe it to be a bug simply because it hasn’t been documented. While I respect their right to their opinions, I must say that such opinions run contrary to the “open mindedness” that science requires. Is this a bug? The answer is simple: I don’t know.

Well I don't know, George (not trying to be funny). If this has come up in a thread, and you did participate in that thread, was your first and final answer "I don't know"?
Let me assume that you did and it was OR that you yourself discovered this anomaly between the versions of VFP, rationalized it exactly as stated above and decided to be satisfied with that "explanation".
Even if that is the case, why cannot another "scientist" come to the conclusion that such an "explanation", self-proposed or otherwise proffered, is not the end of the trail? What if that other "scientist" felt some additional internal pressures like
1) informing "the community" about it in case it might affect some of their production applications;
2) reporting it to MS as a "bug" despite the rationalization, on the bases that:
------ a) It may well not have been by design despite a quality rationale to the contrary;
------ b) It is in MS and the VFP team's interest to amend any documentation that may be relevant to report the fact to VFP users.
Surely such a person does not lose their standing of "scientist" for acting differently than you would, do they?

>
> What is of specific concern here is the fact that, as an MVP, I have a “hidden agenda”. That because I’ve been honored by Microsoft that I’m “in their pocket”, their “shill”, and as David Frankenbach put it, a “sycophant”. Fundamentally, this is an insult. It is an insult, because in trying to be helpful and point out that there may be a reason behind a problem other than simply a bug, we don’t concur with people who are predisposed to think otherwise. I won’t speak for David, but I’m sure that his experience is the same as mine. I have never once been told by Microsoft not to speak negatively about them.

Ahh, let me ASS-U-ME that this aspect of your epistle is directly related to a comment I made in a reply in Re: VFP 7 bug on SET RESOURCE command Thread #657030 Message #658174 that "Some people here have hidden agendas.". If that is NOT the case then feel free to skip this entire paragraph. Yes, you are one who I believe has a "hidden agenda" but you are way way off base in your assumption of what I believe that agenda to be. So that there is no longer any doubt let me state it for you: to ridicule Jim Nelson at every opportunity! There is ample evidence to support this.

Now, to set the record straight on my view of MVPs and "in MS pocket". I admire and respect MVPs, but do get to a point with one or two where their propensity to ridicule my writings or to insult me (usually in other threads and not to my face, as you have done within this very thread) causes some significant loss of the degree of respect. Nevertheless, I do believe that MVPs ARE affected by their status in what they write here. Not, however, to sycophancy at all (save Craig B. who wears his MS "pocket" proudly) but rather to far less criticism of MS and significant more defense of MS. I hope this clears this little business up.

>
>I have said that I view shouting “bug” in the absence of conclusive evidence to the fact is like shouting “fire” in a crowded theatre. You have a right to do so, but any responsible person doesn’t. I think that, at this time, this is important.

This is where, as far as I see it, you have dug yourself a nice big hole.
You have accused me (and Andrus Moor too, most recently) of "shouting “bug” in the absence of conclusive evidence. In later responses in this very thread there is the notion that some people (IE me, Jim Nelson) get their jollies out of increasing the "bug count".
Firstly, in the reasonably recent past (6 months) I personally have "declared" here two (2) bugs.
One had to do with an error in the documentation and that was acknowledged as a bug by MS in message #646698. Your "hidden agenda", of course, had you first dicrediting the report and then arguing that it didn't really qualify as a "bug" even though the MS Bug Reporting facility itself includes DOCERRs as "bug reports". I suppose that as a "scientist" I should have taken your wisdom on the matter.
The other bug that I reported was the now famous "REINDEX no longer removes bloat" (thread #652071) and you persist to this moment to claim that it is not a bug. Your hidden agenda really shines in this one, to the point that you couldn't resist raising it in the thread #657073 when all that I did was to ask you to please stop castigating people for "shouting bug" when you believe there clearly isn't one. Once again you were so quick that you didn't even try out Mr. Moor's download file as instructed before pronouncing such (which, of course, is brilliant "scientific method").
Now let me review the logic yet again for you in this second bug report that has you so upset. I have done a tiny bit more research just an hour ago, visiting the Compuserve forum for the first time ever.
In my message #652071 I showed that there was a siginficant difference between the results of a REINDEX command run under VFP7SP1 versus the same command run on an identical file under VFP6SP5. This fulfilled points 1 and 2 of your scientific method outlined at the top. Now DavidF read that message and, focusing on the incorrect part of the message, declared that it was NOT a bug. Indeed, for the part that he focussed on, I agreed with him. Now in that same reply, however, DavidF also stated: "Please note I'm not disputing the valid part of the bug report about the near doubling of index size. I can tell you that MS is aware of this !!!!! worthy problem.. In addition I found a message on the Compuserve forum, #170613 dated 18-Feb-2002 at 4:03pm by Barbara P that 'MS now seems to be accepting this as a bug' as regards the near-doubled .CDX size observed with VFP7SP1.
You will remember that ChristofL had only mentioned the problem regarding CDX files doubling in size on about May 1 in response to a message asking why some people are not upgrading to VFP7 and that this small mention was the first ever 'notice' of such a bug here on UT. SInce that mention said nothing about REINDEX I thought that I would go ahead and see if the "problem" could be addressed by using REINDEX, rationalizing that the extra size could well be "bloat" that I knew REINDEX nicely gets rid of). I had my old test .prgs around from a message proclaiming that REINDEX did, indeed remove bloat that I wrote well over a year ago. To my great surprise I found that the bloat REMAINED and that the file size was not at all diminished by a REINDEX in VFP7SP1. This, clearly, was a different problem than what ChristofL had mentioned, so I reported it as a bug.
At this point I do not know what the status is of the problem of 'double-sized CDX files under VFP7SP1 because no one from MS has cared to respond to the thread. All I have to go on are DavidF's statement and Barbara P's message on Compuserve, both of which say that doubling of the CDX files under VFP7SP1 is an acknowledged bug. It is certainly likely that the two problems are related, but they nevertheless remain as two separate and distinct problems at this point and nothing that you or DavidF or Christof say about it has an impact on the final answer, which can only come from MS.
So there you have a bug count of two (2). Am I the champion? I sure must be based on the venom in your messages involving me. My slug morality notwithstanding, I continue to believe that I am correct in reporting the REINDEX problem as a bug.


>
>Toledo is well on its way. People, in the past have complained about the marketing of VFP. The degree that Toledo is marketed depends on people upgrading to 7.0. The more upgrades, the more money that will be available for marketing. However, by shouting “bug” at every inconsistency, by refusing to admit that there may be another reasonable and plausible explanation for why something isn’t a bug, undermines the future. Someone who doesn’t know that 7.0 is the most stable version to date, may not upgrade because of this. To sum it up, we’re shooting ourselves in the foot with such.

Maybe this rationale is why it has taken so long for the report about near-doubled CDX files from reaching the UT. If that is in any way, shape or form tha actual case, then it is a far surer way of one's shooting oneself in the foot than coming clean about the whole issue. Or any other issue that affect the product's useability. I point out here that it was a JimS who 'reported' this double-sized CDX files on Comupserve and stated outright that he most likely would NOT upgrade his client's system as planned strictly because of this. Just wanting to confirm that it does have real-world consequences. Now what boat would he have been in if he hadn't noticed and had gone ahead and done the conversion??? He mentioned that his client as very large tables with lots of indices and that it was just not on.


>
>If you’ve gotten to this point, my thanks for your attention and my apologies for being so long winded.

Yes, I got to here the first time too.

regards
slug-go