Tracy,

I made a change to my FoxFix5.ini (which is in the windows directory). The only thing was different is MemoMissingAction. I had it set to 0. So I changed it to 1, as in your example. However, when I run a program with ff_scan() agains the corrupted table, it does not get fixed.

Another thing I noticed though. I can open the table with VFP 6 and go to the corrupted memo record and VFP 6 does not report any problem. When I do it with VFP 9, I get error "Memo file MyFile.fpt is missing or invalid". The program that runs FF_SCAN() is compiled in VFP 6. I wonder if it would make a difference if I redo the program in VFP 9. I doubt it though. At this point I am losing trust in FoxFix as a good program to fix this type of corruption.

Thank you for your help.


>Look at the settings in the foxfix5.ini that you distribute and store in the user's windows directory:
>

>[Memo]
>MemoExistsAction=1
>MemoMissingAction=1
>DetermineBlocksize=0
>UserDefinedBlocksize=64
>MemoDisplayMaxInKB=8
>MemoDisplayMaskNulls=TRUE
>GenerateOrphansTable=TRUE
>OrphansForMemos=TRUE
>OrphansForGenerals=FALSE
>MemoLengthThreshold=0
>

>
>>When I run ff_scan('mytable',-1) (from an .EXE file) against a table that has invalid block pointers (corrupted memo), ff_scan() find no problem with a table.
>>
>>Do you know if ff_scan() is supposed to find these type of problems? I thought it should, because in the interactive mode (using FoxFix Tool), FoxFix Tool finds problems in this table.
>>
>>Could the problem be with the FOXFIX5.INC? What setting in this file (if any) directs FF_SCAN() to find and fix invalid block pointers?
>>
>>Thank you in advance for any suggestions.