Hi Chuckles,

The definition of a bug might be helpful as regards the "bloat" thread, but I don't really think it matters too much to some of the antagonists of the thread. In the thread here (IE not the "bloat" thread) George says categorically: "In order for this to be a bug it must be replicatable with any valid resource file". That was wrong, and he was 'setting his own rules'.

Bzzzzzzzzzzt!! Wrong answer! Thank you for playing. The problem is here that I'm not wrong. The problem is caused by an invalid resource file. When I said that, that fact wasn't completely clear to me. Further, as I stated I would, when the facts became clear, I apologized to Andrus and admitted my mistake. Something not all of us do. That's hardly "setting his own rules."

Nice try, but taking things completely out of context doesn't work with me.

One also has to wonder at why he repeatedly said that he could not replicate the problem despite several attempts and then much later in the thread admitted that he had successfully replicated the problem on his Win98SE system.

Let's see you can't take something out of context, so you misquote hoping no one notices. Not surprising since you've done it, at least to me, before.

I never was able to replicate the problem on any platform, and never said that I did. For the sake of accuracy, here's what I said (MESSAGE#657573):

"Now whether or not it's a bug is another question completely. It could be that the OS is not releasing the file handle properly when the SET RESOUCE TO command is issue. Last night I was able to demonstrate that under Win98SE. Also, if the application resides on a Novell network, that OS is notorious for being slow in this process."

Where in the above do I say I replicated Andrus' problem on Win98SE? The answer is I didn't. I simply couldn't get a file handle to the FPT file. It was a hypothesis of what the might be causing the problem.

Getting back to the "bloat" thread. . . My bug report thread had a simple basis - there was a marked difference between the result of a command xecuted in VFP7SP1 versus the same command executed in VFP6SP5 AND there was nothing in the SP1 documentation alluding to the difference obtained. If you have a look at the "compendium" that I compiled a while back you will see several bug reports based on essentially the same thing, only the command/function/method (name) changing [but otherwise reporting that it works differently between the two versions]. Mine was absolutely no different.
>But there is another reason that I took the time to report it. . . It was a report that the .CDX file sizes had doubled between VFPx (it turns out, up to and including VFP7) and VFP7SP1 that prompted me to re-test the bloat reduction of REINDEX. While Christof had exposed this problem here (on UT), he also later said that this apparently was by design, to fix some known bugs. Remember, Christof's message concerned simply the near doubling of the .CDX file size. There was nothing said to indicate that 'insert bloat' was in any way changed by this revision to VFP7SP1. My test (which was thorough on the specific issue despite pronouncements by some to the contrary) showed NO REDUCTION whatsoever and I was very surprised by this. But here's the other factor: I thought that it was quite possible that this particular aspect was NOT a part of the intended design and that this might well help in diagnosing a real bug in either the .CDX processing or in the REINDEX command.
>
>Now I was dismayed that the double-sized .CDX files problem even existed, not to mention that it was not even known on the UT. I was doubly dismayed when a REINDEX failed to remove 'insertion bloat' any more. Both could adversely impact running production systems! And while DavidF and ChristofL and GeorgeT are all fine fellows, none of them are the VFP Team or even representatives of MS. Their 'decisions' on this matter are as speculative as mine.

One difference. We all rely on scientific evidence. You're relying on strictly empirical. This is science.

My definition of a "bug" is a rather simple one: if something does not act as documented OR if something acts differently between product releases without notice that the change was intentional then we have something called a "bug".

Does REINDEX act differently outside of the change in file size? IOW, does it do what it's designed to do in accordance with the documentation (namely re-build index file)? No. It doesn't.

Further, the term bug, applies specifically (and historically) to software or hardware that doesn't perform as designed, lack of documentation notwithstanding.

Fortunately, I've got a rather thick skin and can take insults coming from everywhere except one specific place. But I do take exception to seeing people labelled as trouble-makers bent on hurting the product simply because they raise a bug. Lots of people on UT have raised possible bugs. Some turn out to be so (more than 75 at last count for VFP7 alone) and many turn out not to be bugs. Raising them is how we find out.
>
Some people here have hidden agendas. I don't. I have, as my sole objective, the continued existence and improvement of the product. Some call constructive criticism negative. George calls bug reports harmful to the product. I differ in both regards.

It isn't raising the issue that bothers me. It's people who insist that it's a bug when there's either scientific evidence to contrary or the problem is not replicatable. I do admit that I've an aversion to using the term, but only when it hasn't been replicated by someone else. That's my personal preference. If that bothers you, too bad.

I don't know you think has a "hidden agenda" here, but it better not be me. As for your "...sole objective, the continued existence and improvement of the product" and "constructive criticsm", let me remind you of something. Aren't you the guy that after banging the drum quite loudly for feedback and/or bug lists, and were told that it was a dubious proposition, turned around and said that you weren't going to submit any more bug reports to MS and, if my recollection serves, urged others to do likewise? Really constructive there, Chuckles. I'll bet people doing what you suggest will make a big positive impact on the product.