Vlad,

Thanks for your reply. I have implemented your suggestion. I hope it works.
In the meantime I have bought and implemented both Stonefield and Foxfix.

However, I didn't have a copy of the 'bad table' to test if Stonefield or Foxfix would fix it. So I don't know if they are capable of detecting/fixing that particular type of corruption.

But the problems have not ended! An index on one table ended up with 'index does not match table'. Stonefield worked fine with this one.

And finally, I have now also been getting what I have seen described as 'C5' errors. I have seen a few posts that describe the identical problem. Here is what has happened:
My table 'respdtl' has a memo field mresponse. In the application, opon doing a 'select from' on the table - in win98 - I get the C0000...5 error, and VFP exits. As per a post I saw on here, when you try to execute 'pack memo' on such a table - you get 'memo field is missing or invalid'. So I tried that, and it was in fact the case. I did a 'brows for not empty(mresponse)'. All the memo data looked good except for the last non-empty row - all the memo data from the previous rows was repeated - plus some ascii 'box' chars between each set of good data. Neither foxfix nor stonefield detected nor repaired this problem. That is EXTREMELY upsetting. I am preparing an email to them to try to find out why.

My user insisted that my 'delete survey routine' would cause the error to happen. I doubted him, because, I have never seen a particular piece of code actually break the data. But it turned out that he was right. My delete survey routine would do a 'delete from 'sometable' for 'somekeyvalue', for six tables, one of which was respdtl. Then it would do a pack and reindex. Either the pack or the reindex would break the respdtl table. I can consistently reproduce this. I replaced the pack /reindex part of the code with a call to stonefield's reindex() method. This seems to have stopped the problem from happening. It is troubling that the pack/reindex would consistently break the memo data. It is also troubling though that neither Stonefield nor Foxfix pick it up. So far the only way that I have been able to correct this one is by restoring the backup.

BTW - Under Win2k Prof - instead of the C00...5 I get .. vfp6run.exe has generated errors. The win2k event log - shows that the error was generated by (this is approximate - I don't have it in front of me) something like 'e:\vfp61\dev\some.exe' - but there is no drive e: on the system


Any ideas?


TIA




>Hi!
>
>This problem was discussed before a lot, and I experiensed it too. The solution is to add FLUSH command just after END TRANSACTION. Accordingly to the Hacker's Guide, table header is not updated for table into which new records are inserted when optimistic buffering used and transaction. FLUSH do update headers and prevents such problem (except for case when computer/network crashes at moment between END TRANSACTIOn and FLUSH commands, that is quite rare).
>
>To fix the table after such problem, open VFP development environment, set up in options to do not use any buffering, open that table in exclusive mode, browse it, use 'Ctrl+N' to add new record in browse window, than delete that record. This should fix the corrupted header. You will not see one (or more - do not know exactly) newly added records and will lose them, however.
>
>HTH.
>
>>A table in one of my applications encountered the dreaded 'can't add rows to the table problem', which, judging by the many posts I have read on the topic here, is a well known vfp problem. I am hoping to clarify some of the issues surrounding this type of corruption, and determining the best strategy for avoiding it/fixing it in the future.
>>
>>Here is a summary of the problem:
>>
>>1) Uon save of a transaction in the system, rows were not being added to the table 'respmatr'.
>>
>>2) Initially I thought it was a failure with one or more 'append from' commands. (I posted separately on the possible issues with append from in the past few days.)
>>
>>3) Debugging the application revealed the following:
>>Respmatr started out with 610 rows. Table buffering was 5 for respmatr. The following commands were issued:
>>
>>begin transaction
>>(do some other stuff)
>>
>>select respmatr
>>append from dbf('currespmatr')
>>**respmatr is a table
>>**currespmatr is a cursor created with create cursor command - currespmatr always has **29 rows
>>browse nomod && shows the added rows, and record count shows as 639
>>llretval=tableupdate(.t.,.t.'respmatr') && llretval is true
>>end transaction
>>end the application
>>open respmatr and browse it - record count is 610. (no buffering)
>>** so at this point I suspect table header corruption - have seen it before. So I:
>>append a blank from the command window - it works. Now, for the time being, I think my table header corruption theory is shot.
>>
>>But just to be sure I did the following:
>>
>>copy the table data to a temp table
>>drop table respmatr
>>rebuild the table structure from scratch
>>append the rows back in.
>>repeat the debug process
>>
>>After this the rows were added properly
>>
>>
>>
>>More on environment:
>>VFP6, Win2k Professional – svc pack 1
>>
>>Further discussion with the client revealed that prior to this there was a system crash – blue screen of death upon ejecting CD from CD drive
>>
>>My questions are as follows:
>>
>>1) I have seen other posts on here regarding this PARTICULAR type of corruption, ie. that rows can’t be added to the table. Will foxfix or sdt or recover find/fix THIS PARTICULAR TYPE OF corruption? Which is better?
>>(I seem to recall that in the past, when I had this type of corruption that the tools I had at the time did NOT detect it)
>>2) Why does the problem only show up when buffering is on and/or when in a transaction (I have seen other posts describing similar circumstance). What is the specific nature of the header problem?
>>
>>3) Are any of these issues addressed/resolved with service packs?
>>
>>4) Are there any win2k (only) settings that minimize the likelihood of the occurrence – e.g caching.
>>
>>5) Can any of these problems be avoided by avoiding buffering and/or transactions? Can this happen WITHOUT a system crash?, e.g. is it related to buffering technique, or particular commands – e.g. insert into vs append blank vs append from?
>>
>>Any ideas, experiences etc. would be greatly appreciated
>>
>>TIA