Long Binary Data
Efficient Image and Photo storage in Access Blobs

Sample Newsgroup Questions

"Long binary data" in Access db
Old Access DB - Long Binary Data - Whats in this field?
Displaying Long Binary Data in a Report
What is long binary data in ms access
2003 and Long Binary Data
Help displaying long binary data
Exporting Long Binary data
jpeg as long binary data
Getting long binary data into Access
Access OLE object/Long Binary Data

Access is well known for a range of common problems when storing images. Using Long Binary Data (blobs) can avoid these problems.

What Is Long Binary Data?

Access displays the text "Long Binary Data" in a field when it contains a BLOB (Binary Large OBject). A BLOB can be any type of binary data, and is most commonly a copy of a file, such as a JPEG photo. The field contains a byte-for-byte copy of the file, so it can be extracted back to the filesystem resulting in an identical copy of the original file.

Although the name suggests otherwise, the Access 'OLE Object' field-type is simply a binary (BLOB) field. While it can be used as the back-end storage for OLE Embedding or Linking, it is also equally capable of storing images, photos, pictures or other files as blobs. Similarly, if you use an Access front-end linked to back-end tables in other types of databases you can use any binary/BLOB field-type with OLE Embedding (such as the SQL Server 'Image' field-type), though this is rarely desirable.

Imaging for Access that's Easy, Efficient & Fast

NO OLE Bloat

NO App Dependencies

NO Complex Coding

NO Performance Penalty

No Overhead.
Images occupy the same space in the database as the original files did on disk (give-or-take a tiny amount of granularity, similar to the file-system). With OLE Embedding JPEG images typically occupy between 20 and 100 *times* the original file size in the database.
Improved Performance.
By avoiding the huge overhead (above) Disk I/O is dramatically reduced. If this is combined with background image decoding (e.g. with DBPix) then forms remain responsive and you can scroll quickly through records, rather than the lengthy 'form freeze' that occurs with other approaches.
No dependencies on specific applications/configuration.
OLE Embedding requires a very carefully controlled configuration to ensure that the correct applications are installed and registered to store and display the data. This is very difficult to maintain and applications are easily broken if a user installs new software, upgrades Office or Windows, or tries to run the application on another computer.
Portable, non-proprietary storage format.
Because OLE Embedding uses the private format of the associated OLE Server application, and further wraps the data in structured-storage headers, and then in Access headers, the data is difficult or impossible to use with other front-ends, e.g. a web front-end written in ASP, PHP etc. With Long Binary Data/Blobs the data can be streamed directly to a browser and used with a wide range of development tools.
Simple Lossless Extraction.
Because OLE Embedding stores the image in a private format wrapped in headers, extraction can be difficult. In the case of 'Lossy' formats (such as JPEG) the image usually needs to be re-encoded/recompressed to get a JPEG file from the field - this inevitably causes a slight reduction in image quality/accuracy, and any image metadata (such as EXIF camera info) will usually be lost. With Blobs the image can be directly extracted from the field and written to disk, resulting in an identical copy of the original file, and without requiring any specific application to interpret the data.

How Do I Use Long Binary Data (BLOBs) in my Access Application?

1) The Hard Way:

Files can be read and written from/to a binary field as Long Binary Data using VBA code. Consequently, in an Access application that handles images, the images can be displayed by extracting the Long Binary Data to a temporary file, then displaying the file using built-in Access Image Control. However, this has several drawbacks:

Performance - Triple Disk I/O
The data must be read from the database, written to disk, and then read into the Image Control.
Complexity
As well as coding blob reading and writing, code must be written to manage the temporary files, avoiding overwriting files that may be in use and cleaning-up temporary files afterwards.
Access Image Control Issues - 'Scroll Too Quick' Crash
When scrolling quickly through records Access crashes if the previous image is still being decoded. A registry modification is required on each system to prevent this.
Access Image Control Issues - Performance
The Access Image Control decodes synchronously - consequently the form freezes until the image has been decoded, which can greatly slow navigating through records. The effect can range from 'annoying' to 'unusable'.
Access Image Control Issues - Configuration
The Access Image Control depends on the relevant Office Graphics Filters being installed in order to display various file-types. In some cases users may need to pass the Office disks around the office and work through the tree of optional components. In the case of Access Runtime applications it cannot be assumed that the Graphics Filters are present, and redistribution/installation can present a problem.

2) The Easy (and Fast) Way:

The DBPix image control binds directly to fields containing Long Binary Data, so it's as easy to use as the standard controls built-in to Access. Images are read and decoded directly in memory, negating the disk I/O overhead and the complexity of managing temporary files. Images are decoded in the background, so forms don't freeze-up during CPU-intensive JPEG decoding, allowing rapid scrolling through records. The built-in user interface allows users to easily load, save, rotate and scan images, and view EXIF info (such as camera settings).