>>>>So if the problem arises near the start of the day, and one relies on "file maintenance" to 'auto-correct' the problem, then how does one 'auto-recover' the data that was added through the day?
>>>>
>>>>Surely VFP could throw a warning message with Retry, Ignore, Fail on EACH write after the problem occurs. That would get people's attention yet let PACK still operate on it.
>>>>If this has indeed been the situation since VFP5 then I'd say we have been short-changed on the issue, and by a long shot!
>>>>
>>>>One can only hope forcefully that something will be done to address this in the first SP for VFP7.
>>>>
>>>Jim,
>>>
>>>Speaking from personal experience, if this is a persistent problem then the issue isn't VFP, but the stability of the entire network. If the network itself is unstable, then it is in the best interest of all concerned (VFP users and others) to make it stable. In the past 4+ years, with 40+ applications, running on 6 different servers, I can think of only one instance of table corruption in that period.
>>>
>>>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.
>>>
>>>Third, neither of us can state with any degree of certitude that the solution of "throwing up a warning" can be implemented easily from within the existing VFP code base. It's easy to say, it may be quite another matter to implement.
>>
>>All excellent logic.
>>
>>But the fact remains that if this is a (significant, in my humble opinion) data exposure that is to be "accepted" within the product, then something more needs to be done by the VFP Team to make this widely known! Relying on a KB article is NOT sufficient - by any means. It needs serious mention in the documentation wherever it might be even marginally related because this (data reliability) is the single most important characteristic of any software product.
>
>So it's the "product's" fault that the OS/Hardware combination isn't stable? Sorry, can't agree.
>
>I think it'd be nice if the KB articles were cross referenced with the documentation, but it isn't something that currently isn't available to me. When I encounter a problem like this one, the first place I check is the KB. It takes precious little more effort for me to do so.
>
>>The best option is for the VFP Team to eliminate the exposure. Allowing that that may be impossible (can they turn write-cacheing off internally?) then the next best is to issue a SERIOUS warning whenever the problem is detected and, in concert with this, make wide mention of the condition throughout the VFP documentation (and how to recover form it too).
>
>No, the VFP team can't necessarily turn off write behind caching. It may being done by the hardware. Further, you wouldn't want to try since other programs (including VFP BTW) may benefit from it. Instability of the OS/Hardware is and should be treated as an exception, not the rule. One of the axioms I use in my job is that you: "Program to the rules and handle the exceptions".
>
>>The situation that seems to be prevalent now is the LEAST DESIREABLE, and by a long shot.
>>
>>Vlad G. has proposed a Wish that addresses this. That can wait for Toledo I guess, but otherwise addressing the problem cannot, and the VFP Team should make this a priority issue for SP1 of VFP7. Even if it is only a documentation enhancement at that time.
>
>First, of you can't throw an error simply because the header's wrong. What that will do will return us to the pre-VFP days of being unable to open the table. Why? Simply because an error indicates that the command can't be executed. However, since it can be executed, you have the opportunity to check for and, if necessary, correct the condition. About the best you could hope for here is something like a VALIDATE TABLE command.

We simply do not communicate very well together, George, so I'll leave things where they are. Suffice to say that the KB article is actually next to useless and doesn't state that it is still a problem in VFP7.
I still cannot 'get' the idea that the VFP Team doesn't know what fixes they've implemented **before** the public actually obtains the final product!