>>I disagree with this opinion. Surely if we have few images we can keep them as separate files. But what's happened when we have thousand records? There is a bottom line: data stored in database! To avoid fpt bloating problem we have to create right data design:
>>1. Master file contains just links (foreign keys) to Image table.
>>2. Image table contain just 2 fields: ID and GenImage.
>> So deletion/creation records in Master file (frequent case) will not affect size of image table. Surely Image Table maintenance shoul include packing.
>
>I agree if you have 1000's of pictures all in the same format, then using a general field with a link (not embeded and that is a key) is fine. When you use OLE for viewing/editing however, the performance is let us say less than optimal. In addition you can not share OLE objects with other users at the same time. Keeping the files separate allows you to do this and avoiding OLE will improve performance. IMHO the web browser as a multimedia display tool has some merit.

That's right for BMP images. Other image formats actually are not OLE linked objects but just some data which can be used by some OLE Container OCX (from VFP standpoint).