Hi!

When you store binary data into the Memo binary, it is also stored into the FPT file, but with original file size. General field cause growth because following things:

- in General field data from OLE Application are stored which is used to display/edit stored type of the file. Thus there are always (10% in average) bigger size of data stored in FPT.
- Specially for such kin\d of files like JPEG - they're unpacked into the pure not compressed bitmap image. That is why the data growth is so large as Hilmar pointed.

Finally, the main disadvantage of the General fields is that you require to have OLE Automation application to display and work with the data stored in it. This application should be installed on every client machine. It is recommended to use General fields only in case you use little number of file types, for example, only BMP files or only DOC files. When you plan to store wide range of file types in the database, better do not use General field.

Memo binary (Memo field created with NOCPTRANS option) is the best choise when saving data into the VFP database, however, as I already said, beware about FPT file size limit.

To answer your question completely:
The grows of FPT file is depended not only on the field type you use to store data. Take a look to the SET MEMOWIDTH command in VFP. When you specify large size before table creating, the growth will be greater when you have a lot of memo fields and records. When it is little, performance might degree. You can see why when look to the structure of the FPT file - data stired there in chunks, and all tails of each memo field leave some space just for chunk space. Growth here in average is 0.5*(SET("MEMOWIDTH"))*{Total Number Of Non-Empty Memo Feilds In All Records} BTW, SQL Server seems use the same approach, but chunk size there is even more greater (I do not know exactly that number, and seems it is not configurable, at least I did not found anything), so the growth will be at SQL Server too (But, again, not that large as for General field in VFP). BTWBTW, that is why it is not recommended to store empty string in the memo field - just because extra space taken for each such extra useless data.

On SQL Server Text field type could not be used to store BLOBS. Image is ideal but tricky to handle from VFP, and I do not know exactly if there are some disadvantages (though I did managed to get 2.5 MB binary files within a second using SPT) related to reliability or server overload.

>Hello Hilmar
>
>It does sound like a lot more space may be used up storing Blobs this way.
>I wonder if the effect is constant or if it is only noticed if you have a few Blobs to store in the FPT.
>
>Maybe it is a one off penalty and does not get much worse if you add a lot of Blobs.
>
>Vlad has doen some things in this area I will forward this to him:)
>
>Thanks Hilmar:)
>
>
>
>
>
>
>>>Which database is better at storing and retrieving Binary Large Object data.
>>>
>>>
>>>Security issues aside......
>>>Is it VFP or SQL Server.
>>>
>>>Is either of these a good technology for storing this type of data or are the BLOBS better dealt with as independent files in a folder.
>>>
>>>All comments gratefully received.
>>
>>I have no experience with SQL Server.
>>
>>In VFP, I did some testing. The results are interesting:
>>
>>A JPG file (a picture of one of our shoes), kept as a separate file, used about 50 KB.
>>
>>Inserted into a general field (in a test file), the DBF + FPT (mainly FPT) increased in size by over 1 MB. This is a factor of over 20.
>>
>>Therefore, I only reference the filename in an 8-character char field. (8 character is enough for our purposes, since we use the article code; path and extension are the same for all files).
>>
>>BUT: perhaps general fields are easier to manipulate in some cases. However, because of the tremendous difference in file-size, if required, I would copy them into temp files on-demand (like, for reports).
>>
>>HTH, Hilmar.