>Dmitry,
>
>I experienced this regularly at one customer many years ago- last century- just after 10am daily. Nothing to do with the app or the network, but with some process that kicked in and caused enough of "something" to temporarily render the dbf invalid. I say "temporarily" because after the app crashed out, you could restart it and now the dbf was fine.
>
>Have not seen this in many years since most of the user GUI was moved to web or data moved to SQL Server. These days it's not seen by us against collections of indexed dbfs with tens of millions of static lookup values.
>
>My advice = you can waste hundreds of hours pursuing this will-o'-the-wisp. If you are lucky enough to be able to isolate it to a particular table, maybe wrap some TRY...CATCH including OEVENTS or SLEEP breather for the OS, then try again. If you're not writing to the table- maybe rebuild it completely with a SELECT * INTO MyNewTable with full reindex in case there's some historic sediment or something to do with collate or who knows what.

I wonder if Chen can check the VFP code (I suppose he has decompiled the entire compiler) and see what actually causes the ISO error. Or what triggers the error message.
AFAIK, this error - ISO - is the only show stopper that we cannot deal with (other than TRY - CATCH).

UPDATE. A message from Jeff Leason confirms that the error has something to do with the CDX. So, in this case, makes it easier to deal with.