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).

>
>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.

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.

good luck
>
>
>Todd
>
>
>>The indexes are not breaking because of anything VFP is doing (or not doing). There are VFP solutions than run for years without index repairs.
>>
>>When you index - make sure to delete the tags and INDEX (not REINDEX). There was a thread on this a few days back.
>>
>>It might be good to hire a contractor to check and tune your network. At the very least, have your wiring checked. Try to determine why it is failing - VFP can be forgiving to a point - but you've got some connectivity issues making your app look bad (know what I mean) - so get it fixed before it becomes an embarassment :-)
>>
>>It would be a shame to spend all sorts of bucks and still have the same problem. Whats with the gigabyte file (shouldn't some of it be archived?).
>>
>>
>>>Thanks Sylvain
>>>
>>>The UPS is already in place, and so is the indexing happening after workhours but still i get this error.
>>>
>>>As for changing backend..i am trying to get it approved by the heads.
>>>
>>>What am i missing here ??
>>>Dinesh