>>>>Hi Mike, Brandon,
>>>>
>>>>I should have been more specific. The images are stored in a general field and I use
>>>>
>>>>append general table.logo from (filename).
>>>>
>>>>To get them in. I have a backdoor way to get it in by defining and opening a paint window and
>>>>
>>>>modify general table.logo in window picture
>>>>
>>>>but it's problematic. I have to get users to cut and paste and sometimes it doesn't work either.
>>>>I figure it's the graphics card on some machines. It may be unresolvable.
>>>>
>>>>I'll get the user to send me a screenshot.
>>>>
>>>>Luke
>>>
>>>Rule #1: Avoid general fields, AT ALL COST
>>>Rule #2: If you absolutely need to use a general field, see rule #1
>>>
>>>General fields seemed like a good idea when they arrived, but experience has showed that they cause more trouble than they fix. Instead you can use a blob field, or separate image files with only the file name and relative path in the table.
>>
>>Or you can have the image's file name and subfolder name (if you use those) be functions of the associated record's PK and (if necessary) the image control's name, and you don't have to store anything about the image in the table.
>

>Actually this is how I do it in one of my applications which has more than 200,000 images. The images are distributed into 100 different folders to reduce the number of images in each folder. For instance an article has a value of '1234567890' in the image field, a character field to allow leading 0's. This file which contains this high quality image is O:\data\images\hq\1\2\1234567890.tif, while a thumbnail is in the file O:\data\images\thumbs\1\2\1234567890.jpg.

I read somewhere (on UT, I think) that it is not a good idea, with Windows, to have more than 1024 subfolders, so my naming convention is constructed to respect that maximum.