Hi Bill,
>
>>>>As long as they realize that this is their problem, they're entitled to place as little value on their data as they like.< s >
>>>
>>>It IS frustrating, but they accept the data loss.
>>
>>Having a good deal of experience in business management, I'd be highly critical of the way they run their business. However, it is their loss.
>
>Agreed! They won't be convinced that the investment in infrastructure would be cost effective. Believe me, we've tried.

I'm sure you have, and from what you've just said, you did it the right way as well, for it is an investment and one that, over the long haul, pays dividends.

>>>>>Question. Don't you need exclusive access to the .dbf file to validate/fix it? Or is there another way?
>>>>
>>>>Basically, yes. I suppose that one could attempt to "fix" the situation via the low-level file functions to correct the necessary bytes. However, it would seem to me to be a case where the "cure" was potentially more dangerous than the "disease".
>>>
>>>Even using LLF, you need exclusive access though, right? We have a LLF routine that does correct the problem, at this point we dial in and run it. I'm getting ready to put in on their menu so I don't have that support call to deal with. Loop through all the DBFs in the DBC and verify the headers, fixing those that are broken.
>>
>>Yeah, in VFP you do. You might be able to write something in VB or VC++, however, that didn't. Why not simply PACK the tables when the headers are corrupted? Unless I'm terribly mistaken (and it wouldn't be the first time), that should fix the problem. Plus, if there are any memo files involved, they'll be dealt with as a bonus.
>
>Did pack always fix the record count in the header? It would make sense. I don't know why we developed the other solution unless pack didn't work... Next time it happens (ARGHH!) I'll have to try pack first. I've already got a pack option on the menu!

AFAIK it did. Internally, VFP counts how many records it writes to the temporary file, and uses that information to update the header.