>Hi,
>
>>>
>Our code checks all of this and responds appropriately. In this case the error message from aerror is "Index does not match the table. Delete the index file and re-create the index."
>>>
>
>If this happens in VFP8 and not VFP6 the stricter table validation in VFP8 may have a bearing - see 'SET TABLEVALIDATE' in the documentation. Presumably you followed the suggestion and deleted and recreated the index ?
>
>>>
>Prior to this error, the index for the table was fine.
>>>
>I'd be more inclined to think that prior to this error you were unaware that the index was not fine<s>. I'd certainly be very wary of assuming that the TABLEUPDATE *caused* the error.
>
>Regards,
>Viv
Hi Viv,

Thanks for your comments. I certainly did not intend to be presumptuous. We just tested this extensively prior to listing it as a problem.

We did test with several different versions of the table in question. Althought this table structure did contain other characteristics that might be in question, there was never a problem with the index in the file, it was simply in the error message reported.

Prior to submitting, we also recreated the test case with a simple table containing 4 fields and 5 records. We set tags on two of the fields so that we could emulate the problem as previously described. We removed any code from our test form which might confuse the issue and were still able to demonstrate this problem.

We then submitted this as an incident to Microsoft. It has been verified that it is a VFP8 bug and is in their bug list. In the latest copy of the VFP9 beta that we have here, the problem still exists. However, in the current VFP9 beta at Microsoft, it has indeed been fixed. So we can look forward to this being resolved in VFP9.

I am posting this here just to inform the community. Please refer to my previous listing for details.

We have found a temporary workaround for this problem. Once the error occurs, the various values of the field (eval(thefield), oldval and curval) are no longer accurate. If the user were to make the change again and save, the save occurs properly. We were able to do this automatically behind the scenes, by determining which field was not accurately saved, restoring that value to the previous field value and saving. We then re-set the field to the value we wanted to save and saved again. This process causes two additional tableupdates to that record, but does solve the problem for now. This approach doesn't do anything to improve our performance, but at least the data is accurate.

I hope this information is helpful.

-Nancy