OLE Linking and embedding rely on a suitable application being installed and registered for the particular
file-type on every machine. Not many graphics applications support the OLE Linking/Embedding functionality,
and one of the most common in this scenario, MS Photo Editor, was withdrawn in Office/Access 2003. The
registration is easily changed (eg when a user installs new software), and therefore hard to control.
Configuration problems like this are therefore common, especially since 2003, and this is just one of the
drawbacks to this approach - even when 'Linking' there can be a *huge* storage overhead, for example.
To work with external files (ie 'Linked') it is usually best to store just the filename (or generate it
from an Id, for example). Paths also can be generated at runtime, so the images can be accessed centrally,
or the location changed easily, without needing to update thousands of records.
Similarly, if the images are to be stored actually in the database, using raw-binary (blob) storage instead
of OLE Embedding can overcome all of the overhead, configuration and other potential issues.
Although focusing on OLE Embedding, much of the following content is also relevant to OLE Linking, and
contains further info plus references and links to free and commercial alternatives and implementations:
Common Access OLE Object Photo & Image Problems (including Access 2003).
http://www.ammara.com/articles/accesspictureole.html
Efficient Access Image Techniques
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
