[ Previous entry: workBLOGS . smasn and FX ]
[ Next entry: article . Is the Rich .Net Client ready yet? ]
workBLOGS . VF6 and corruption
Since the day I upgraded to Visual Foxpro 8, I considered it knocking out VF6 in all departments. And indeed it does prove itself far superior than the last version that was bundled with Visual Studio. That was until yesterday when I discovered that a certain Database Utility application I created could open databases that were corrupted by power interruption and 'magical reboots' (possibly caused by computer viruses).
I have already installed NAV on a client's computer which could possibly have eradicated that 'magical reboot' problem but I created a patch still... just in case. Problem is, when I tested it last week on the client's computer, the patch won't work so I have to use that old but reliable Database Utility I have created to open the corrupted database and delete the last record which is often a blank one. After that the corrupted database is fixed.
It was yesterday when it came into my mind that probably the reason that UTILS can do these things was because it was compiled in VF6... and after a number of isolating-the-problem experimentation, I found out that the said theory was right. You see, when VF6 encounters a corrupted database, it still opens it during the use DatabaseName line but when you do the database manipulations such as Append Blank/Replace (Add) or Delete it generates an error. With Visual Foxpro 8... once it encounters a corrupted database, even in the start (use DatabaseName line), it generates an error at once.
However Visual Foxpro 8 still has an advantage, it displays the name of the corrupted database while VF6 just points to the line of code where the error occurs. Here are the exact lines:
Fatal error: Exception code=C00000FD
Error loading file - record number 12. FRMPROFILE
Combining the strengths of both version, I created a small module patch in VF6, compiled it in .exe form and called it from the main VisualFoxpro 8 module using the ShellExecute API.
DECLARE INTEGER ShellExecute IN shell32.dll ;
I'm still studying how the Flush+TableUpdate approach could also help solve this problem but for now I'm using the patch above and an auto backup feature that copies the database to a different folder every five hours.
I also added two features to that Database Utility application yesterday, a feature that saves the structure of the database and the indexes along with it which is useful for documentation and reference related things and a MERGE databases feature. It was a special addition since it was done with my little Angel on my lap playing with a diskette and a floppy drive while I'm doing it.
Disclaimers are for castrated EARTHLINGS.
Powered: GREYMatter | GM-RSS