The error message tells you that you have corrupted data. Earlier versions did not test so thoroughly, so you're lucky if the corruption has not caused you any problems.
SET TABLEVALIDATE ON should ALWAYS be your choice. Performance degradation? Hardly noticable.
SET TABLEVALIDATE OFF means you are willing to take a big risk. You may end up with no data, or even worse, wrong data. I have been there myself, no problems so far, so why bother? Then one day BOOM, many customers had the address of other customers and all kind of mess. Luckily I take backups every day.

>I discovered the other day that VFP 8 adds some new table validation features when opening and writing to tables. I got error message 2091 when opening a table, with the message that the file was corrupt. After some brief searching, I found out that this validation can be modifed with the SET TABLEVALIDATE command. However, the documentation for this command states that this validtion can result in "decreased scalability" because it must lock the file header. Can anyone verify that there are noticable performance issues because of this? My current thinking is that if it did cause slowdowns I would turn off validation for those tables that are shared heavily, but only written to by a few applications. My company still has quite a few apps in VFP 6 or lower, so it would be useful to know how much impact on performance the default table opening mechanism there is. As far as the corruption of the tables go, is something that happens a lot? We currently don't get much table
>corruption that I know of, but with this new validation perhaps it might be happening more frequently and we don't know about it!
>
>Thanks for any insights
>
>Brian Vander Plaats