Hi!

Mike, I think the problem is not in the corruption itself but in the reliable ways to work with data and easy-to-use ways to repair problem, maybe, repair it on the fly.

For sure, this problem requires much more attention than just check at the table opening. For what is worse, in VFP7 and earlier versions, when I browse table in design-time with corrupted header record counter, add new record in browse window, then remove it - header is automatically fixed. This was never described (at least I did nto found it) and MS recommends to use repearing tools.

The question is - why not create repearing tools native for VFP? Who knows better how to repair corrupted table (with any corruption)? :-)

Also, see my wish#247 and thread#580276. I propose to add more documentation related to avoiding of header corruption (FLUSH). Also, make header always updated by default (so no header corruption issues for newbies at all). When need to switch off header auto-updating after each insert (for performance purposes), just provide new sys() function that would be still useful for experts. Just look how many messages here about header corruption, and you will understand that it is needed to enable auto-updating of header by default, because newbies are not experienced with this issue at all, and it is not described well in help files.

As an example, 3 years ago, when I worked as a developed on one VFP application, I spent 8 working days in communication with client, making tests, measurements and finding solution, asking questions in forums etc. - all this just around header corruption. This was, indeed, very hard experience, and VERY unpleasant for VFP as a product.

PLEASE, make something to this.


>>I have a corrupted table error 2091. Which means I need to get my header back in sync with my table. There is a topic about this on the Wiki, but I am just raw enough not to be sure if I should be looking at the dbf or dbc in the HexEdit app. My guess is the dbc, but then I am not sure what row to look at.
>>
>>Anyone done this before and want to give me a clue?
>
>More than likely you'll be modifying the .dbf. And the post on the Wiki is wrong, it's bytes 5-8 that you're modifying, not 4-7. 4-7 refers to the byte offset, not the actual bytes themselves. VFP 7.0 also does not do any "auto repair" that I am aware of, as implied in the wiki post.
>
>Additionally, we do additional file size checking in VFP 8.0 that we didn't do before, hence the reason the file can be opened in 7.0 but not in 8.0. The table is still more than likely corrupt (though maybe not, since there was a since-fixed bug that reported corrupt tables when they weren't), 7.0 just didn't complain about it. The formula is as follows:
>
>FileSize - SizeOfHeader = SizeOfRecord * NumberOfRecords
>
>If that's not the case, VFP throws an error. Fixing this can be a little more tricky than the "off by one" header corruption, since you don't necessarily know how the file size got corrupted, nor what to trim or add to fix it.