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

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

>>
>>Is it still nice up there? The first week of the month, when I was up there, was terrific.
>
>VERY UnNovember! NO complaints here. We're supposed to hit 70 today! By Sunday we're supposed to return to reality. <g> Hopefully we're not using up all the heat allocated for the next three months!

You're about like we are, except here the leaves are still falling from the trees (and will be for another few weeks). When I got back, people were asking me about the weather up there, and I told them it was about 5-10 degrees cooler. We're supposed to be around the upper 60's to-day with 78 this weekend.