>>It tells us that something is looking for a variable or field that it cannot find. It is NOT in your form because the same things happens when you run the same code in a prg. We know the prg isn't doing anything to refer to the variable or field, so the only other place that the errant reference can be coming from is the data tables themselves.
>
>so it would seem...
>
>>It could be an index key expression,
>
>but there are no indexes in the current table because I've just created it as a query from another table. And I've checked the original table using David F's little routine and everything is HD. And in any case - I get the problem from at least three different original tables.
>

What about FOR clauses in any of the indexes?

If all looks OK, I'd try doing a DELETE TAG ALL. and rebuild the indexes on the suspect table.

>> one of the events or properties associated with a table or field in the dbc
>
>they're all free tables.
>
>>, a currupt index, or some other aspect of the data tables.
>
>but that requires multiple versions of similar files (not copies - entirely different data sets) to share the corruption. Possible but near zero probability.
>
>In any case - lets take a step back from trying to analyse the cause. I said in opening this thread that I couldn't expect anyone else to do that and what I really want to know is why I'm getting that form of error message instead of the normal vfp error handler. If I can switch the damn thing off, perhaps the cause will be somewhat more transparent.
>
>When vfp is in this mood it gets REALLY irritating! The problem is I cannot know if this is really a vfp fault, or some really stupid code that I can't see for staring at it!
>
>
>Regards
>
>Harry