Hi!

>>This is not a problem, this is a "feature" ;))
>
>A poor 'feature' to say the least. FLUSH should not be necessary, if VFP works as advertised. In a multi user context, how could the header update be delayed?
>I will explore the use of FLUSH, just the same.

As I said, I really do not know why it is there. In my opinion, its purpose to allow organize "quick" inserting of large number of new data records. Remember that VFP is the quickest engine not because a lot of patches for every hole, but a lot of different ways of doing things and allowing a lot of things and flexibility. Here I agree in such feature. Anyway, I wondered why MS do not make it not used by default (something like SET HEADERUPDATE ON by default and allow switch it off for better speed). Or, why not put a large-font warning at many help pages that prorammers should use FLUSH after adding new records to prevent data corruption? Just adding record to the list of wishes for VFP.Next version...

>
>>The header corruption is a known problem and already discussed many times here. Header is not updated for performance purposes - it remains in the memory buffers for some time until you use the FLUSH command or close the table. The solution is to use FLUSH command each time after inserting new record or END TRANSACTION command. After we used the FLUSH problem went away.
>
>I fully understand the corruption issues. What concerns me is that there is a wide acceptance of major flaws in the data engine which are not being addressed.
>This is just one of them.

There is a wishes list and MS maintain also a database with bug reports and similar wishes. Read threads and discussions here about these things. From what I understood, MS VFP team work very hard to fix many things that could be MUCH more important than mentioned here problem. That is why. Think of level of importance - when you overburdened or rush, you're trying to do not do things that are less important.


>
>Geoff
>
>>
>>>This very problem has been causing me some concern in the last few months.
>>>
>>>In the program to demonstrate the problem, the header count is manipulated to corrupt the table, and yes, there is no error.
>>>
>>>But I believe that in the past, this would have produced the old 'not a table' error. I also believe that in VFP, the header is now said to be automatically corrected.
>>>
>>>To test this, I made a second version of the test prg to reopen the database and the table. It reported the same corruption, so it seems clear that the header is not being fixed. I think that is also demonstrated in the program itself, since the file is reopened. No question of caching in the additional test - I restarted VFP.
>>>
>>>In my own experience, I had cases where up to 1000 journal records were not added to the table before the users spotted a problem. Nasty. I did discover that the last journal written in one instance was 1 char short of its correct length. I assumed that the correction routine relied on the assumption that if the header count was incorrect, it relied on the physical length always being correct in terms of the header + n times the record length.
>>>
>>>The KB article carries a review date of 31 March, and the problem is still there in VFP7. Isn't it about time this problem was addressed?