>Hi George
>
>>Second, if the problem is acute, and the powers that be are either unwilling and/or unable to resolve it through upgrading the hardware, then I would take it as my responsibility to validate the size of the table and fix it, if necessary, each time it is opened. The validation simply would not add significantly the I/O overhead. That's a far better solution than sitting around waiting and hoping for someone else to resolve the problem for me.
>>
Hi Bill,


>We have one client whose infrastructure is, shall we say, less than stable <g>. They experience the header corruption about once a quarter. They can/will not fix it. So they have to deal with the data loss.

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 >

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

Is it still nice up there? The first week of the month, when I was up there, was terrific.