What is actually stored in the OLE object field?

[Pavils Jurjans]

Hallo,

Could someone please enlight me, telling what kind of data actually is saved
in the MS Access OLE object field?

I did some testing, and wrote a code that takes a file, reads it, and stuffs
the data into OLE object field. Since in no time I pass any information
about what *kind* of data these are, then in table view mode I see text
"Long binary data" in that field.

Now, I can right-click that field in the teble view mode, and choose "Insert
Object" from the menu. The I can choose "create from file", and browse for
certain file, and finally, I can choose to link or embed that file in the
database. After choosing a jpg file, and clicking Ok, I get "Microsoft Photo
Editor 3.0 Photo" in that field. So, obviously, the field also contains at
least two more data properties -- an OLE server ID, and file name, if it is
linked rather than embedded. Or maybe it contains MIME type information? I
can't really get any documentation about these tech specifics of MS Access
BLOB fields.

So, what actually is preferred way to store file information in the database
then. Please don't come up with cliche "It's generally not suggested to
store binary information in the database", I am very well informed. I just
want to know if it is suggested to store anonymous binary string in the BLOB
field and then provide MIME type in separate text field, or it's better to
store the binary data type along with the data in the same BLOB field. If
it's the latter, I am afraid that I don't know how to separately tell the
field, what type the data is, using standard DAO syntax.

Rgds,

-- Pavils

 

[Exponent]

The Access OLE Object field is a long-binary/BLOB field that can be used to store any type of binary data.
If you store raw binary data in an OLE Object field you will see "Long binary data" in the field in table
View.

OLE Embedding and Linking are Access font-end techniques to store 'objects' in a binary field (such as
the 'OLE Object' field-type). They use the associated 'OLE Server' application to store the object/file,
which is stored using some internal private format of the particular OLE Server. AFAIK these formats are
undocumented, and header structures, lengths/offsets and content are entirely variable, may be subject
to version differences etc.

There can be particular issues with compressed images, as some OLE servers store uncompressed copies which
can be 10 to 100 *times* the size of the original file (e.g. for jpeg), and it can be difficult to extract
the original data without loss of compression, quality &/or metadata.

OLE Embedding also relies on a very specific client configuration - the relevant applications must be installed
and associated with the particular file-types; this can be a maintenance headache if you need to use this
approach on several systems.

Storing raw binary data can avoid these issues and others, but keep the MIME type identifier in a separate
field.

 

[Pavils Jurjans]

Thanks, that clears this up

The Access OLE Object field is a long-binary/BLOB field that can be used

to store any type of binary data.

If you store raw binary data in an OLE Object field you will see "Long

binary data" in the field in table

View.

OLE Embedding and Linking are Access font-end techniques to store

'objects' in a binary field (such as

the 'OLE Object' field-type). They use the associated 'OLE Server'

application to store the object/file,

which is stored using some internal private format of the particular OLE

Server. AFAIK these formats are

undocumented, and header structures, lengths/offsets and content are

entirely variable, may be subject

to version differences etc.

There can be particular issues with compressed images, as some OLE servers

store uncompressed copies which

can be 10 to 100 *times* the size of the original file (e.g. for jpeg),

and it can be difficult to extract

the original data without loss of compression, quality &/or metadata.

OLE Embedding also relies on a very specific client configuration - the

relevant applications must be installed

and associated with the particular file-types; this can be a maintenance

headache if you need to use this

approach on several systems.

Storing raw binary data can avoid these issues and others, but keep the

MIME type identifier in a separate