Hi

I did not come here to fight. I addressed my post to Garrett, who authored the article, in the hope that he might pass it along and have the Fox team take a look at it. I hope that I said enough to show that the failure to show an error has serious consequences. I can think of several valid reasons why Garrett might not reply, and that is quite OK.

It is not a tenet of the Fox religion that one may not draw attention to its shortcomings, or to the fact that solutions to them have not been addressed.
One of the 'problems' is that the Fox team, for whom I have the highest regard and many of whom I have met at Devcons, do not always understand the practical issues in the field. That is not a criticism. Many of dismiss a problem as trivial, until we realise its importance, and take a serious look at it.

Geoff

>Please, do not speak with me like I'm taking Microsoft position and trying to defend this "feature". I completely agree with you and I passed the same time when customers screamed about this bug.
>
>AND, please, do not start here discussions like this. When you want to show some feedback to Microsoft - go ahead - write notes at their MS site. IMO this is more efficient than here. I already added this issue to the Wishes list. What else is needed? Do you want to organize "Party of fighting against header corruption bug"? Everybody comes here for *solution*, not to fight.
>
>Sorry.
>
>There are 3 possible solutions. One is close and open again a table each time new record added, or FLOCK() it for a short moment.
>
>Second is FLUSH after each END TRANSACTION or table records adding without transaction.
>
>Third is hrow away VFP at all if you think it is not reliable, and use, for example, SQL Server. Personally, program reliability is depended on the *programmer*, not on the tool programmer is using. Of course, tool should help to build reliable programs, and this help should be consistent. Header corruption is one of such inconsystent places in VFP. However look how VFP evolved from FPD and you will understand that it is TOO MUCH WORK for Microsoft to fix every issue. Header corruption probably is the one that can take a lot of time to fix. Think form economical point of view - if bug fixing cause spending more money for fixing than just teaching users - you will not fix it. The same is here.
>
>
>>Hi Vlad
>>
>>Are you saying that data integrity is not important? That it doesn't matter ifa thousand records are not added to a table, and there is no warning of this until the end of the month when a critical report is to be printed?
>>
>>I don't believe you are saying that at all. If you are, come and talk to some of my customers <g>.
>>
>>And how do you work around this problem? You can't open every table a second time as an LLF in order to check and fix. I have worked out a possible solution, and that is to commit the appended record with its primary key, and then force a read. If it was lost, I have a problem.
>>
>>BTW, I understand that FLUSH can be a problem with Novell, according to notes in the framework I use.
>>
>>The header count is an integral part of the X-Base philosophy. The failure occurs when it incorrect, and is directly or indirectly responsible for the record not being added, but no error is reported. Fixing the problem would be a lot easier and much more effective than what you are suggesting.
>>
>>Sure, VFP is very fast in some areas, but the way that speed is achieved works against it in others. I know that this could be changed without a great deal of effort, but the lack of response to these posts, apart from yourself, points to a blind acceptance of the way things are, not what they should be.
>>
>>Geoff
>>
>>>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?