Hi George,

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

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