Hi Jos

In an application I use daily at my company, we have an application with roughly 100 000 pictures, and to overcome the speed issue with many pictures in one directory, I have put all the pictures in a directory tree with 'main' directories called 1, 2, 3, 4, 5, 6, 7, 8 and 9, each with subdirectories 1, 2, 3, 4, 5, 6, 7, 8, 9 and 0. So in total I have 90 different directories for the pictures. All my picture filenames are unique 8 digit numbers plus extension, and placed in the subdirectory which corresponds to the first two digits in the filename. So file 12345678.jpg is in directory pictures\1\2, picture 98765432.gif is in directory pictures\9\8 and so on. The 'value' of the filename is always in the range 10 000 000 to 99 999 999, so I have plenty of space for more pictures.

I have a function to find the file when the filename is given, and 'getting' the picture file is extremely fast. This also means that my filename field is only c(8) and does not take up too much space. The file type I get from the extension.

Earlier I had all pictures in one directory, and it was slooow because no file system 'likes' too many files in one directury.

>I have to agree with you Tore. I have done a lot of work with pictures and have found that storing them in a logical folder structure is a better solution that using memo fields. The bloat issue is a big one if the stuff changes. I also like the ability to edit a picture directly without having to extract it and reinsert it. Not to mention the 2Gb limit.
>
>Later.
>
>
>>Hi Jonathan
>>
>>Your comment that it is not more logical to keep each picture in separate files than to include them in a memo file is your own opinion, and of course you have every right to have your own opinion. However, I must argue that I can see absolutely no advantage in doing so, but it mat depend on the number of pictures, and whether they are static or may be changed in some way. I will argue that in most cases seperate pictures is a much better idea, and far more extensible. Also keep in mind that if you want to change some pictures, with your approach you will run into memo file bloat.
>>
>>In all the apps I have made over the last 20 years, I have never had a case where your method would have given me any advantage.
>>
>>>I'm a month late to this thread but for storing picture I've have good luck using a binary memo field instead of either a general field or storing the name of a separate image file. Doing so reduces file bloat (caused by the general field containing not only the image but also a preview picture), and in my mind it's no more logical to keep each picture in an entirely separate file than it would be for any other column of data. How-to details were published in the Advisor Answer's column of July '99's Foxpro Advisor - basically you use APPEND MEMO [fieldname] from [filename] OVERWRITE to get the picture into the binary memo field and COPY Memo [tablename.fieldname] TO [filename] to get it back out.