>>Well, I can tell you this about the damaged file. It is the same as the real file though the first 58202 records (based on a casual inspection). Then there are three records of mostly zeroes. Then nothing. The real file has 931247 records.
>
>It could've been a copy of an archived version of the table, but the zeroes at the end suggest that this is not the case. If you open the file with a binary editor, you'll see nothing but zeroes, or garbage, at the end of the file. My hunch is that this is due to a network problem.

Wow! I hadn't actually looked at the trashed file with a hex editor until now. Big clue: starting in the middle of a record is BROWSE output.

I know this because I can see the text from the banner of the BROWSE window. "Please select a record and press Esc..." and then cursor field heading names appear:

Curreserv Type
Curreserv Subass
Curreserv Unit

etc.

Then about 25 zero bytes and the file terminates.

Whenever I create a temporary cursor, I put "cur" at the beginning of the table name.

So (believe it or not) this is what it looks like: data that should have been sent to a temporary file on the local disk was directed to the network file along with some indication to truncate the file.

WHOA! I don't like the looks of this at all. I've been swearing that VFP could not do this to a table.

SQL here we come.

Peter