Hi Greg
My suggestion, and you will most likely also hear this from others, is NOT to use a general field for pictures. Use a field with the complete file name including the path in stead, e.g. p:\data\pictures\picture122.jpg. The field with this inco can be a character field which is long enough for the most extreme paths, or a memo field. This solution is much faster and more flexible. I have programmed in dBase/foxplus/foxpro/vfp for nearly 20 years, and I have never used a general fields, simply because it has no benefits.
>I have a manufacturing parts book application that needs to print pictures of parts assemblies in a Visual FoxPro report. This application will be installed by hundreds of end user customers and must work without any add-ons or additional costs for distribution.
>
>Currently the pictures are stored in a general field. What is very strange is the size to hold the pics in the table is many times larger (almost 100 times larger) than the space they take up on the disk.
>
>225 Jpeg pictures ranging from 6-10k each take up a total of 1.5 MB in my picture folder.
>
>The table holding the pictures however consumes 125 MB of hard drive space. Without the pictures in the table the table size drops to a miniscule 79K. Does anyone know what VFP is doing underneath to ballon those picture sizes? Is there anyway to stop it?
>
>If the size were the only issue it wouldn't be so bad. The big problem is that printing anything is VERY slow. I assume the slow down is also related to the problem of VFP dramatically increasing the size and the overhead in managing such large structures.
>
>I've looked into taking the pictures out of the general field and accessing them through the File... option in the report but I can't figure out a way to specify what the file is for each record in the report. I was thinking there maybe a way to hack the FRX to make the File... report option dynamic but that doesn't sound like an easy solution.
>
>Right now I'm only working on the 2003 version of the Parts Book. The application will soon have data from 1997-2004 which by rough calculations could put the table size over 1GB which is completely unacceptable for pictures that should consume no more than 10MB on the disk.
>
>
>Any ideas how to speed this up and shrink it back down or is this a solution that Visual Foxpro can't handle well and I need to look to an alternate development environment?
>
>Thanks a bunch!!!
>
>
>Greg
