George,

>To begin with, there’s the title of this thread. It indicates that the REINDEX command is supposed to reduce the size of the index file associated with a table, but now it doesn’t. Therefore, this is a bug. However, in checking the documentation in both FPW 2.6 and VFP 7.0, can I find no reference to this being one of the intended purposes of it.

When we look at the help file topic for REINDEX, it would appear that the command is designed to be used when one has done something outside the scope of FoxPro itself, to change the data in a table without having the index open. Like me writing a chunk of VC++ to rip through a DBF and make some sort of global change to the rows of data. Or a better example of using something like dBase to read the VFP tables, or VFP to read dBase tables neither one is going to have updated the other's indexes.

>Now assuming (a bad practice, but one that I must indulge it) that I haven’t somehow missed something along the way, it would seem to me that the reduction in the size of the index was a simple by-product of the algorithm. It occurs to me, that using the command to combat index bloat and corruption became a common practice based on this undocumented feature. In short, it feel into the pool of “common knowledge”.

The biggest problem with REINDEX is that it can not deal with most real index file corruptions. It needs to be able to read the file in order to glean the index expressions from the file itself. If there is a wiped out link somewhere along the pointer chains inside the file then it probably can't correctly find all of the tags. This is why I think it's been more commonly published to use a metadata store of indexes (or even just a prg or method) and use that in conjunction with a DELETE TAG ALL (DTA) to be sure that you can recover from corruption. Periodic use of DTA with INDEX ... also ensures the best possible B+Tree structuring, which read/update performance.

Personally, I've never coded REINDEX into any production app I've ever done.

>One of the things that I learned a long time ago was not to use undocumented features to resolve problems. In this case, going all the way back to my first usage of FoxPro (FPD 2.0), I used a combination of a re-ordering of the table based on its intended natural order, combined with a meta-data table to re-build the indexes from scratch to combat both bloat and corruption.

The biggest thing about undocumented features is that they can be yanked from a future release.

>Now jumping ahead to the present day, I must also (based on information that both you and Christof Lange have provided) jump to the conclusion that the change in the behavior of the command is intentional and intended to combat these problems.

If the earlier splitting of nodes in the tree was done to better optimize normal record insertion then I'm all for it. But, again to make it clear to everyone lurking the thread, this has nothing at all to do with "CDX bloat".

If the overall CDX size increase is instead a bug that occured in the SP1 release then I'm in favor of getting it fixed. Especially when viewed in the context of 2gb file size limits.

> If so, it begs the question of why we’re wasting so much bandwidth on the subject.

Perhaps the question of the day.

>For some reason, I’m reminded of another change in behavior that’s also been called a bug. As you know, the expression 1 / 0 = 1 / 0 produces different results between 6.0 and 7.0. This has been called a bug. However, in re-calling the problems caused by certain printer drivers with division by zero, it occurs to me that this may (note “may”) be by design to help combat this problem. If it is, then why would this be a bug also?

Well since the Fortran programs I first wrote would ABEND most horribly on divide by zero errors I just got used to writing code to make sure I had valid denominators before I tried to use them. If this change broke folks code, well then it just did, there's not a whole heckuva lot that you or I can do about it is there? *s* I'd say, "Why do you expect VFP to handle an invalid numerical operation in the first place?"

Sometimes behavior of a language must change to make it more robust. I know backward compatability is a huge issue, but supporting some inane backward thing isn't the best long term solution.

>So help me out here, David. Have I totally missed the boat on this?

I don't think you've missed any pertinent point.