>>>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.

I seriously doubt that VFP could do that.
The OS, on the other hand, might be a good candidate, especially if write cache is enabled (workstation or server) or OPLocking is active, an intermittent RAM problem and such.


>
>SQL here we come.
>
>Peter