>>George,
>>
>>>>Hi George
>>>>
>>>>I understand how it can occur, and how to fix it. But difficult to fix when there is no warning of the problem, and that is my main point. Once VFP finds a problem, it appears to simply ignore it.
>>>>
>>>>I suspect the issue goes back to VFP3, and the problem hasn't really been looked at since then. Tanks for your comment.
>>>>
>>>Geoff,
>>>
>>>The problem, as I see it is this: If VFP throws an error in these cases, then the table doesn't open and fixing the problem becomes more complex. OTOH, if it doesn't, it would seem to me to be less of a problem. All you'd have to do is calculate what the size of the table should be (using HEADER(), RECCOUNT(), RECSIZE()) and then compare it to the actual size on the disk. If they don't match, then you know there's a problem, and fixing it becomes simple.
>>>
>>>From my POV, this then puts the process in the area of file maintenance. I believe that it's a good idea to periodically PACK tables and re-build their indexes in order to reduce the problems of memo and index bloat.
>>
>>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.

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

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.