Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Header corruption and KB Q293638
Message
From
12/11/2001 15:30:55
 
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00580276
Message ID:
00580595
Views:
29
Hi Vlad
>
>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.

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

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?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform