Hi Jos,

The size of the images can vary drastically. Thus, it is difficult to estimate a maximum size. However, I will venture to guess that images will generally range from 15KB to 80KB. Although, there will likely be some extremes on the high end (which I may limit with a size limit feature). You could have an image of small dimensions, but that has sharp and varied color contrasts. Those photos can be very large in size, since a lot of data is needed to display the varied color mix.

As for the maximum quantity of photos, that could also vary drastically depending on the usage. However, if I go with storing the images within the fpt files, then I will distribute the storage among many tables, which I did in the past anyway, since the application was designed that way to meet specific user needs. Realistically, I doubt that any table would have more than 500 to 1000 images stored within it or referenced by it. By the way, I would not try to store a high quantity of images within the general field. I think that is pushing it, and one of the reasons why I was looking into storing the binary data instead. It could be that I need to think about using VFP as a front end to something like MySQL for image based applications.

I'm probably going to do some testing, to see how VFP tables and memo fields handle binary image data under various scenarios and conditions. If I go ahead with that, I will let you know about my results. Although, I'm tending to think that I really should just reference the picture files, instead of storing the actual picture data (as you recommended).

Dave


>Hi Dave. Just curious -
>
>1) how many images do you want to store, max.
>
>2) what is the size of the largest image, max.
>
>Later
>
>
>
>>Hi Jos,
>>
>>Yes, the fpt file bloat is huge, especially when storing images to a general field. I created an image storage system years ago, which stores images in general fields. However, the fpt bloat is too extreme. I wanted to keep the images within the fpt file at that time, since it seemed like it had some advantages for the end-user. I was aware of the bloat issue, but I wanted to store the images within the database, to provide some minimal security. I would still like to do this with the update I'm building, but there are many issues involved, especially if I store the images as raw binary data in a memo field. I would need to convert the binary data back into picture files every time the user wanted to view the images, which may not be very efficient. I know this can easily be done, but it may defeat some of the minimal security features I had in mind. In the end, I may need to just store the images on the hard drive, as you mentioned. Besides, there is better security in using the
>>windows encryption system
>>
>>I did a little experimenting, and storing the raw binary data in a memo field does not bloat in the same way that a general field bloats. The picture preview component in general fields, is what apparently causes the extreme fpt bloating. On the other hand, storing raw binary data in memo fields seems to inflate the fpt file only in direct proportion to the size fo the original picture file (which is much more acceptable than what happens with general fields). However, there is the 2GB limitation, which could be a problem even when using memo fields. Picture files vary quite a bit in size. Some are very small (17kb) and others are very large (1MB or more).
>>
>>Dave
>>
>>
>>>Hi Dave. You can store any binary data into binary memo fields. You can write binary memo fields out to disk. Also check out FILETOSTR() and STRTOFILE() functions amongst others. Be aware of memo file bloat - updating the memo field of the same record creates "bloat" and will add excess size to the FPT file. Will you be updating these memo fields? Also, note that the memo file (and VFP file) has a max size of 2Gb. What is the average size of your images and how many do you want to save? The usual technique is to leave the images on disk and use a char field to hold the drive+path to the image.