I have a corrupt FPT file that I cannot repair. The DBF that is associated with it has 52 records of information. Ive pin-pointed where the corrupted fields are. I have a memo field with the name mplacement. There are exactly 4 so called corrupted records in the mplacement field. The corruption starts at record 18. Records 18 21 seem to be the corrupted ones. Records 1 17 seem to display information correctly. When I export the information from this DBF into an XLS, it only goes to record 17 and then quits, leaving the rest of the records out. When I open the FPT with a Hex Editor, the data displayed ends with record 17, like there is no more data.
Here’s the tricky part. When I open the application and go into 4 records (other than the 4 corrupted ones) and enter data into that mplacement memo field, it magically fixes the FPT and I dont get the Error 41, Memo file is missing or invalid anymore. When I open the FPT back up in a Hex Editor, it shows me records 1 17 and my newly added data for the 4 entries at the bottom. I still can’t seem to recover all of the data from the memo field from records 18 52. Ive got backups (at the time of corruption) of the DBF and FPT so I can try anything. Any help is much appreciated.
Forum Topic
FoxPro memo field
-
In DBCs you can define Insert/Update/Delete Trigers that run beforehand and you can already access the new values and so this could be a solution. But it's a bit overacting to double store memo texts in the fear of file corruption. You may migrate data to a more solid server database. Actually I'm working on some kind of replication via triggers which would help storing everything double, but it's taking twice the time to write then. I opt for creating a log table without indexes and have a secondary process reading in from the log into replication dbfs. But that's going too far here. This sample code will write some memo field to a text file and can be put into a tables insert and update trigger as logmemo("tablename","memofieldname",tablename.ID).
tablename.ID should be the primary key value, which is used in the file name to identify into which record the memo.txt backup file belongs. You might change the strtofile() to append to a single file instead of generating new ones for every insert/update.
1#Define ccBackupPath "\\server\data\backup\"
2Procedure logmemo()
3 Lparameters tcTable, tcMemo, tuID
4 Local lcBackupFilename
5 lcBackupFilename = ccBackupPath+Transform(tuID)+" "+tcTable+;
6 " "+tcMemo+DTOS(Datetime())+Sys(2015)+".txt"
7 Strtofile(Eval(tcTable+"."+tcMemo),lcBackupFilename,.f.)
8 Endproc
Refer to the following thread for some possible solutions. maybe it'll help you somehow.
<click here for link> -
If you fail to solve this problem in General, then you're in a pinch you can try to recover the data from the file using DBF Recovery Toolbox. <click here for link>
Also You can create triggers on a VFP database. Check out modify procedure to create a procedure. and in modify structure you can set the triggers.