>SNIP
>>
>>This MS Rep took my program back and put it on an even larger computer which would, in his words, spread the timings apart so that they could 'see' what was going on. The result was that, in fact, the index (CDX) was being corrupted due to VFP. The solution was to not recycle the last record in the table. Now, having implemented that solution in our Call Centre (which runs 24/7 and handles in the area of 10,000 calls per day), the index corruption practically disappeared.
>
>Now that IS interesting, indeed!!! Since you say it was a few years ago, we can only hope that the problem has been fixed (I say only because few fixes are made public).

It would be nice to know... but I believe only time will tell. I have refused to remove the 'fix' that the MS Rep suggested because things were (yes, were) running so smooth for a couple years now.

>
>>
>>Today, interestingly enough, I have recently upgraded our systems (which runs in 5 different locations) to VFP 7 SP1, the index corruption appears to be returning... So, question to Microsoft - Have changes been made in SP1 that would cause index corruption? I am totally open to providing routines which do full index testing (while systems are running) but I have yet to resurrect my IndexCorrupting program to see if SP1 may be the culprit - I will get to it though given the problems going on in the systems...
>
>I assume you are aware that there was (is still) a bug in the VFP7SP1 REINDEX command. That bug produces indexes that are (for all intents and purposes) DOUBLE the size of any .CDX it processes. Could your new problems be related to the size of the .CDX?
>The REINDEX of a VFP6 installation can be used to reindex such tables without enlarging them and without apparent negative effect. There were fixes made in VFP7SP1 to do with indexes but I **assume** that they were outside of the REINDEX command.

Yes, I do know and use Stonefield Database Toolkit for performing all reindexing, packing, or structure changes. I do try to leave some of these issues to experts like Doug for knowing the 'best' way of doing something.

>By the way, there was another problem described some time ago with indexes by another person here and I believe it applied to pre-VFP7SP1. While he too reported no fix, a bypass (developed with MS help, if I remember correctly) seems to have been very effective for him.
>That bypass was to put 2 "dummy" fields at the very start of the table(s) in question, the first as Integer and the second as Char(10), effectively ensuring that the PK was NOT in position 1.


Thanks, I may try this though I do not generally like to add 'garbage' to my data structures but if it would work... I will keep this in mind and thanks!

>good luck
>>
>>
>>Todd
>>
>>