Did you ever get to the bottom of this?

Another thought is that the INSERT statement opens the table again (I believe) and maybe that's going over the limit of peer-to-peer (10 shares).
I could see VFP getting a bit "confused" in such a case, given that the same-named table is already open... possibly it associates the error returned with the other instance of the table.

good luck


>Then wouldn't it insert the record into that table instead of returning the error instead?
>
>>Is it possible that there is another NOTES table that is being found for the INSERT INTO?
>>
>>Good luck
>>
>>>Any idea why using the insert command would return a table is corrupted message but using append blank and gather does not?
>>>
>>>*This code generates the error:
>>>*Notes is not the selected table but is open in the current data env
>>>
>>>INSERT INTO notes FROM MEMVAR
>>>
>>>*This does not generate any error
>>>
>>>SELE NOTES
>>>APPEND BLANK
>>>GATHER MEMVAR MEMO
>>>
>>>EXCLUSIVE IF OFF on all workstations in the config.fpw file.
>>>This only happens at one site that has multiple Windows XP workstations sharing VFP tables on one of the Windows XP workstations.
>>>
>>>What is so strange is the error returned is that the table is corrupted yet the table is already open, can be opened later and updated and appended to fine, and also it can be updated any other way (like the append example above) without generating the error. However, at this location, on all workstations, whenever INSERT INTO is issued, the table is corrupted message is returned.