ACC: Why OLE Objects Cause Databases to Grow

ID: Q123151

The information in this article applies to:

SUMMARY

Advanced: Requires expert coding, interoperability, and multiuser skills.

A Microsoft Windows OLE object is stored as an OLE stream that consists of two portions:

Microsoft Access stores the entire OLE stream in an OLE wrapper in a type of Long Binary field.

The amount of information used to render the object is often greater than the size of the object itself. Adding such OLE objects can increase the size of a database significantly. To minimize size increases caused by adding OLE objects to a database, use either of these methods:


MORE INFORMATION

An object's rendering information can be in any of the following formats:

An OLE server offers formats in order from the server's most-to-least preferred format. An OLE client enumerates the available formats and uses the first compatible format. Generally, you can override the OLE client's choice of formats with the Paste Special command.

Typically, either WMF or DIB is chosen, because OLE servers render these formats most easily. For example, Microsoft Word for Windows typically renders using WMF, while Windows Paintbrush renders using DIB. An OLE client can always choose the format it prefers first. Because DIB is a form of BMP, most servers that render in DIB also render in BMP, although DIB is often 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 of information described earlier in this article. The server must send information to render the object using BMP, WMF, or DIB, as well as native data that can be used to edit the object. When this occurs, the compressed format is converted to a format to be rendered. The size of the OLE stream is the sum of the converted rendering object, the native data, and some OLE overhead information. Because the OLE stream contains all of this information, small objects in compressed formats can become quite large when stored in a Microsoft Access database.

One way to work around this behavior is to store the object as an icon. If you 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 with rendering information consisting of only the icon rather than the complete object, using significantly less storage space in the database. When you double-click the icon, the OLE server is launched with the native data that the icon represents.

Another example of a small file growing to become a large OLE object is a Microsoft Word file that contains complex text formatting or an image on the first page of the document. The small amount of native data requires so much information for rendering that the OLE object is quite large. To work around this behavior, place a page with simple formatting at the beginning of 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 is available (metafiles provide better scaling than bitmaps). If WMF is not available, 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 add more rendering formats to the three default formats that Windows supports. Microsoft Access does not currently support this OLE feature.


REFERENCES

For more information about OLE Objects, search the Help Index for "OLE Objects," or ask the Microsoft Access 97 Office Assistant.

"Microsoft Object Linking and Embedding Programmer's Reference," Volume 1, pages 418-420

Additional query words: big 


Keywords          : IntpOle 
Version           : 1.0 1.1 2.0 7.0 97
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: April 8, 1999