OLE Data Field

[Ian Benton]

I have a table in Access2000 that includes an OLE data
field which I was hoping to include small (75-500k) jpeg
objects, embedded, not linked.

However, when I insert a jpeg image the database expands
by several mbytes. In one case I inserted a 500k jpeg
image and the database grew by over 24 (thats twentyfour)
mbytes! I don't mind putting up with some increase in
size for the convenience of having the object embedded
but nearly 50 times bigger is a bit much to stomach.

Is there some way to get Access2000 to recognize the true
size of the embedded object or turn on some sort of
compression? Yes I know that linking would avoid the
issue but I really need the data to be embedded since the
database has to be portable.

 

['69 Camaro]

Hi, Ian.

Is there some way to get Access2000 to recognize the true
size of the embedded object or turn on some sort of
compression?

No. Access converts graphics files from their native formats to *.BMP
images when storing them in the database. As I'm sure you are aware, *.BMP
formats of equivalent *.JPG files are much larger. Storing graphics files
in the database is one of the most common causes of database bloat.

Yes I know that linking would avoid the
issue but I really need the data to be embedded since the
database has to be portable.

If it needs to be portable, then consider storing the graphics files on a CD
that the database application can link to.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Guest]

OK, thanks. That is what I suspected (8^( but of course
the manuals give zero information on the subject.

I guess I will have to use linking instead.

Ian

 

[Exponent]

Using OLE Embedding to store compressed images can cause an overhead of up to 200 *times* the size of the
original image file (in the case of highly compressed jpeg files). This technique can cause an uncompressed
copy of the image, and possibly also an uncompressed 'preview' copy, to be stored in the table, hence the
overhead.
A more detailed analysis is available here:
http://www.ammara.com/articles/imagesaccess.html

The OLE Object field is perfectly capable of storing jpeg and any other binary data without this overhead,
by storing the files as raw-binary/blobs (i.e. the conventional way). This also avoids several other problems
with OLE Embedding.