You need to have a suitable 'OLE server' application installed *and registered* for the particular file-types/extensions
that you will use.
Note, however, that there can be serious drawbacks to this approach. These 'registration' issues frequently
cause configuration problems (other packages may register for these file-types, or maybe the user doesn't
want to have to have Photo Editor as the application associated with some particular file-type). Furthermore,
Photo Editor was withdrawn in Access/Office 2003, and there is no equivalent replacement.
There can be a storage overhead of typically between 10 and 200 *times* the original file-size when using
jpeg, so your database may hit the size limit after a few hundred images instead of 10's of thousands.
Metadata is typically lost, along with the compressed data, so 'extraction' back to a jpeg file requires
lossy compression.
If you want to store the image data actually in the tables you can store raw-binary (blob) data to overcome
all of these problems. Otherwise work with external image files.
For additional info on this, including references and links to commercial & free solutions:
Common Access OLE Object Photo & Image Problems (inc Access 2003)
http://www.ammara.com/articles/accesspictureole.html
Efficient Access Image Storage – OLE Linking & Embedding vs raw-binary storage:
http://www.ammara.com/articles/imagesaccess.html
--
______________________________________________________
http://www.ammara.com/
Image Handling Components, Samples, Solutions and Info
DBPix 2.0 - lossless jpeg rotation, EXIF, asynchronous
