>> In at least one case it is related to the data in the table because if I skip the reload step above and add records to an empty table, then I don't see the problem. But I can also load that same ascii data to an identical table with a different name and I don't see the problem.
>
>This actually may provide a clue. When I worked at Fox we'd run into really strange problems that ended up being the result of a high ASCII character in a field, program file, etc. Since the problem doesn't occur until you reload the data from the ASCII file, I'd suspect that there's actually something in the data that's causing the corruption.

Though there were times when Fox was sensitive to some special characters (like chr(0x8d) aka high-enter, chr(26) aka EOF and such), I doubt that it may be something that sensitive that would carry the problems over to an ASCII file and back. With today's codepage translation capabilities, Fox is expected to handle high chars smoothly. If some of weird chars appeared in an impossible place (instead of a delete marker, or in a binary field yielding impossible numbers - like in a datetime), it wouldn't pass through ascii export/import. Such values would come back blanked or truncated (try Val("4524Z22") and you'll get 4524).

There was probably something else wrong - with so much binary info in .dbc's memos, it could be that the index key was improperly stored there, or something like that.