Dear Ken,

I read your mail with interest as we too frequently suffer from the problems you describe. I have mentioned it here on the thread before, but the only solutions offered were to reindex the indexes. This is OK in the short term, but within a day or two the problem reoccurs or in some cases hours. We have also tried to identify problems using foxfix to no avail.

We have taken the issue up with Microsoft, but are struggling to pin it down on a piece of code small enough to send them. The problems are compounded by the fact that the index corruption is sporadic and we are unable to replicate the error in development. Maybe you could press them on this issue as well, or even send them the code where the problem occurred.

One thing of interest is that our most troublesome index comtains a STR expression aswell, the table is buffered(5) and the tableupdate is nearly always successful.

If you find any solution to this problem, please do not hesitate to contact me and likewise, I will keep you updated on the progress of our investigations.

Regards

Mace

>We experienced a problem with a structural index (CDX file) which we can not explain and the fix appears to be be magic.
>
>The problem:
>
>When updating a table in a batch we compare the new data to data in the table. If the record is found, it is updated with the new data, if it is not found we insert (INSERT INTO) the new data in the table.
>
>After this the new data does not appear in a grid used to display the table's data (after the update routine runs).
>
>Quitting the app and viewing the table in the development mode. We still do not see the new data. We see updated data (data which was changed) but not data records which were inserted. After issuing REINDEX the inserted data majically appeared. We came to the conclusion that the indexes were not being rebuilt.
>
>The table was buffered (5) and the TABLEUPDATE was successful.
>
>The Fix:
>
>The CDX contained an index based on the expression :
>
>STR(rc_ch_key) + STR(rc_c_pre) + STR(rc_c_year)
>
>Where : rc_ch_key is an integer (foriegn key)
>rc_c_pre - number field
>rc_c_year - character field.
>
>This index was used to identify the records (there is no primary key).
>
>We removed all indexes (DELETE TAG ALL) and used INDEX ON to rebuild the indexes. We did not rebuild the above index and create indivudal tags for rc_ch_key,rc_c_pre,rc_c_year. We replaced the SEEK in the code with LOCATE. The routine works fine now.
>
>Our problem now is this same scenario is being used throught this app and we are fearful that we will get bit again.
>
>What could of happened?