M
Medha Kulkarni
I have Access database that contains column of type “OLE Objectâ€. This column
can store any OLE object including images, word doc, excel sheet etc.
My task is to read this OLE data from “OLE Object†column & store it into a
temp file say data.tmp so that the OLE data can be retrieved without any
information loss.
Since the definition of OLE object storage is not documented (contains some
header information before actual data), simply extracting the field contents
as a byte array using GetChunk (0, fieldSize) and saving it to disk does not
work.
I could not find the convincing solution on internet, which reads any OLE
Object from Access table column, saves it in a file in such a way that, the
original OLE Object data can be retrieved from this file without any data
loss.
I thought of one approach as described below:
Any OLE Object file has some standard signature. Following table gives
signatures for some of the file types:
Signatures File Extn
D0 CF 11 E0 A1 B1 1A E1 DOC, DOT, PPS, PPT, XLA, XLS, WIZ Microsoft Office
applications (Word, Powerpoint, Excel, Wizard)
42 4D BMP DIB
This approach will read the OLE Object data using DAO library & RecordSet
using GetChunk (0, fieldSize) method into a byte array. Now this byte array
will be compared for above file extensions & whenever the match is found the
corresponding byte offset will be saved. All the data before this byte offset
will be rejected (the OLE Object Header part of byte array) & the data
starting from this offset will be stored as the actual data in temp file.
This approach seems to be working for “.bmpâ€, “.doc†& “.xls†files. i.e. I
was able to save OLE Object data for a bitmap image, word doc & excel sheet
without any data loss. One thing I observed was, the size of the new file
constructed from OLE Object was greater than the corresponding original file
size. This may be bcos, apart from header information & actual file data, OLE
object stores some additional information at the end (after actual data
bytes).
This approach may not work in the situations where actual data bytes =
Signature Bytes
One more disadvantage is, it involves lot of comparisons with all the
possible file signatures till the match is found. Apart from this, this
approach should work for most of the cases.
Any other major disadvantages of this approach which I am overlooking?
Any expert comments on this approach will be really appreciated.
Thanks a lot!
Medha.
can store any OLE object including images, word doc, excel sheet etc.
My task is to read this OLE data from “OLE Object†column & store it into a
temp file say data.tmp so that the OLE data can be retrieved without any
information loss.
Since the definition of OLE object storage is not documented (contains some
header information before actual data), simply extracting the field contents
as a byte array using GetChunk (0, fieldSize) and saving it to disk does not
work.
I could not find the convincing solution on internet, which reads any OLE
Object from Access table column, saves it in a file in such a way that, the
original OLE Object data can be retrieved from this file without any data
loss.
I thought of one approach as described below:
Any OLE Object file has some standard signature. Following table gives
signatures for some of the file types:
Signatures File Extn
D0 CF 11 E0 A1 B1 1A E1 DOC, DOT, PPS, PPT, XLA, XLS, WIZ Microsoft Office
applications (Word, Powerpoint, Excel, Wizard)
42 4D BMP DIB
This approach will read the OLE Object data using DAO library & RecordSet
using GetChunk (0, fieldSize) method into a byte array. Now this byte array
will be compared for above file extensions & whenever the match is found the
corresponding byte offset will be saved. All the data before this byte offset
will be rejected (the OLE Object Header part of byte array) & the data
starting from this offset will be stored as the actual data in temp file.
This approach seems to be working for “.bmpâ€, “.doc†& “.xls†files. i.e. I
was able to save OLE Object data for a bitmap image, word doc & excel sheet
without any data loss. One thing I observed was, the size of the new file
constructed from OLE Object was greater than the corresponding original file
size. This may be bcos, apart from header information & actual file data, OLE
object stores some additional information at the end (after actual data
bytes).
This approach may not work in the situations where actual data bytes =
Signature Bytes
One more disadvantage is, it involves lot of comparisons with all the
possible file signatures till the match is found. Apart from this, this
approach should work for most of the cases.
Any other major disadvantages of this approach which I am overlooking?
Any expert comments on this approach will be really appreciated.
Thanks a lot!
Medha.