Hi Stefan

Like you say, the best practice may depend upon the situation. But your argument that solution #3 is not practical for an system with many files, I ask you to read my answer earlier in this thread to Jos about how I spread the pictures into 90 different directories. My main application has roughly 100 000 pictures, and it is damn fast, if I may say so! Also in my application the filename field is actually encrypted, if any competitor want to find out which picture belongs to which record, he will have a lot of work. And since we constantly add new pictures and change existing pictures, the other alternatives are simply not practical.

>prima facie it is only logical to store image data in table columns if the database 'owns' this data, just like any other data. However, there is a scarcity of controls/components that can work with immediate image data rather than disk files.
>
>There are three ways out of this dilemma:
>#1: use controls that can handle immediate data (or at least ODBC data)
>#2: write the data to temporary disk files for the benefit of dumb components
>#3: store references to external image files in the database
>
>Which of these options - or which mix - is best depends on the specifics of the application. #3 is not really feasible if obfuscation/encryption is required and the overhead can become prohibitive unless you have only a small number of images. #1 is the easiest if you work in a fully programmable environment (say, Delphi/C++) because usually there is at least some native control that understands some kind of in-memory image (say, .BMP) and translation from or to many interesting formats can be achieved at zero cost via gdiplus.dll.
>
>In Fox it is not quite so easy but the LeadTools OCX can handle in-memory images for display/conversion, and for reporting we use option #2: the images in question are converted to temporary TIFF files that are deleted when the report is discarded. Internally, we pass images around as (objects containing) memory handles rather than as strings, because the excessive copying caused by the latter was simply unacceptable when I wrote the code in the last millenium (*g*), and even today Fox is not very efficient at handling megabyte-sized strings. The conversion between memo fields and memory handles is handled by two trivial, generic FLL functions.