Bloated classlib =VCXVCT VFP7

[dgfletcher]

Has anybody else experience dramatic inflation of a VCT file?
We had one go from 548k to 17meg from one version to the next after only minor bug fixes to a couple of the classes.
After locating the point where the size ballooned, I compared the VCX's of the differing versions and found a bunch of seemingly blank records in the bloated one (there were a few such in the non-bloated one too). These didn't show up in a browse as having empty memo fields, but browsing with a field descriptor like oclass=left(class,20) they had no readable data. Desperate, I deleted the "blank" records - ten or twelve of them, packed the table and the file size dropped back to 500k.
Any ideas about how this came about? Could it be the result of someone opening the VCX in VFP 8?
Thanks.

 

[rgbean]

Like any other table, when things are replaced in a memo field, the old stuff is just copied to a new area of the "FPT" file, delinked and the new stuff added (if it didn't fit in the original area). Everytime you change anything in a method, it may get a new section for the method code, then it will recompile that code and the object code will get a new section in the VCT file. You can use the PACK technique you used, or you can use the class browser to "Clean up the Class Library" (pack it!).

Yes, if you switch VFP versions, it may decide to totally recompile the whole class and replace ALL the object code! Actually a good idea if you do use it under a different VFP version - see COMPILE <fn> CLASSLIB.

Rick

 

[Mike Lewis]

Dgfletcher,

Yes, I agree with Rick. I always make it a habit to pack my VCXs (and also SCXs) every week or so, and especially before a full backup. It makes dramatic difference to the size of the source files.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[dgfletcher]

Tkanks. The mystifying thing was that the file size didn't creep up as the memo fields got modified, at least not much. It exploded by a factor of 40! Packing didn't help because the bogus records weren't deleted. As far as I can tell the memo fields had 0 length, but I guess I'll go back and check (bad version is faithfully preserved in VSS - could VSS have messed up?)
All is more or less well that ends more or less well (discounting wasted time...) but I'm puzzled.