This article was previously published under Q123151
This article has been archived. It is offered "as is" and will no longer be updated.
Advanced: Requires expert coding, interoperability, and multiuser skills.
A Microsoft Windows OLE object is stored as an OLE stream that consists oftwo portions:
Information to render the object.
Native data that can be modified by the OLE server that created the object.
Microsoft Access stores the entire OLE stream in an OLE wrapper in a typeof Long Binary field.
The amount of information used to render the object is often greater thanthe size of the object itself. Adding such OLE objects can increase thesize of a database significantly. To minimize size increases caused byadding OLE objects to a database, use either of these methods:
Make the object easier to render (by lowering the resolution of the object, or decreasing its physical size).
Display the object as an icon.
An object's rendering information can be in any of the following formats:
Windows Bitmap format (BMP)
Windows Metafile format (WMF)
Windows Device-Independent Bitmap format (DIB)
An OLE server offers formats in order from the server's most-to-leastpreferred format. An OLE client enumerates the available formats and usesthe first compatible format. Generally, you can override the OLE client'schoice of formats with the Paste Special command.
Typically, either WMF or DIB is chosen, because OLE servers render theseformats most easily. For example, Microsoft Word for Windows typicallyrenders using WMF, while Windows Paintbrush renders using DIB. An OLEclient can always choose the format it prefers first. Because DIB is a formof BMP, most servers that render in DIB also render in BMP, although DIB isoften offered first. Microsoft Access always chooses DIB over BMP.
OLE servers that can display pictures stored in other compressed formats,such as the JPEG format (JPG), must still send the two portions ofinformation described earlier in this article. The server must sendinformation to render the object using BMP, WMF, or DIB, as well as nativedata that can be used to edit the object. When this occurs, the compressedformat is converted to a format to be rendered. The size of the OLE streamis the sum of the converted rendering object, the native data, and some OLEoverhead information. Because the OLE stream contains all of thisinformation, small objects in compressed formats can become quite largewhen stored in a Microsoft Access database.
One way to work around this behavior is to store the object as an icon. Ifyou do not need to display the object in a Microsoft Access form or report,you can store the object as an icon that represents the object type.Storing an object as an icon causes the OLE server to send the object withrendering information consisting of only the icon rather than the completeobject, using significantly less storage space in the database. When youdouble-click the icon, the OLE server is launched with the native data thatthe icon represents.
Another example of a small file growing to become a large OLE object is aMicrosoft Word file that contains complex text formatting or an image onthe first page of the document. The small amount of native data requires somuch information for rendering that the OLE object is quite large. To workaround this behavior, place a page with simple formatting at the beginningof the document, or store the document as an icon.
OLE has a preferred order for using the standard presentation formats.Regardless of where WMF appears in the format order, it is used if it isavailable (metafiles provide better scaling than bitmaps). If WMF is notavailable, DIB is preferred over BMP. OLE currently supports only WMF, DIB,and BMP.
One of the options in the OLE Specification calls for OLE servers to addmore rendering formats to the three default formats that Windows supports.Microsoft Access does not currently support this OLE feature.
For more information about OLE Objects, search the Help Index for "OLEObjects," or ask the Microsoft Access 97 Office Assistant.
"Microsoft Object Linking and Embedding Programmer's Reference," Volume 1,pages 418-420