 Home |
| dbPix |
| Download |
| Order |
| Testimonials |
| Support |
 Tutorials |
| Samples |
| KnowledgeBase |
| Links |
| Revision History |
| Documentation |
| Search |
| Contact |
| Site Map |
Introduction - Example - Other Issues - Solution - Implementation - Resources Any suggestion of storing images in MS Access (such as jpeg photos & other graphics/pictures) usually meets with a response such as:
Example
OLE Embedding and Linking clearly cause a very significant storage overhead, and the more highly compressed the original image, the higher the overhead. In the worst case the database grew by over 180 *times* the size of the image file that was inserted. The raw-binary overhead, however, is negligible. Other OLE Embedding IssuesBecause the data is stored in the private format of the OLE Server application, we cannot simply extract it to a file or stream it to a web browser etc. In most cases the only way to 'extract' the image involves obtaining an uncompressed bitmap version of the image, and then re-compressing it to a file of the original format. In the case of JPEG, the lossy nature of JPEG compression will cause a further reduction of image quality, and any metadata will be lost (e.g. EXIF digital camera info or jpeg IPTC info).The relevant 'OLE Server' application must be installed and correctly registered on any machine that will use the database. This can be difficult to configure and maintain and is a common source of problems, for example if a user installs new software which 'takes-over' the relevant file registration, (e.g. for ".jpg"), or when new versions of Windows or Office/Access are installed. Update: Office 2003 no longer includes an OLE Server application for various image formats (including jpeg) and may remove/replace existing OLE Server applications, usually causing existing images to display as icons, and new ones to be inserted as a package. The SolutionStoring the images as raw-binary (BLOB) data avoids all of these problems. By storing the image in it's original compressed format the overhead is avoided, and the image can easily be extracted directly back to a jpg file (without loss), or streamed to a web browser, used with other development tools such as VB, etc. Metadata is preserved, and the dependency on an OLE Server application is removed.Implementing Raw Binary StorageImages can be loaded from files into an OLE Object/binary field (and extracted directly back to files) by using the ADO GetChunk and AppendChunk methods in VBA or other languages. In this way it is possible to display an image by extracting it to a temporary file and then using conventional file-based approaches, such as using the Access Image Control (though there are caveats with this control).A far easier and more powerful solution is provided by DBPix, which can bind directly to binary fields (including an Access Form or Report dataset, or an ADODC in VB) and provides most commonly required functionality without a single line of code. As well as ease-of-use and efficiency, DBPix overcomes numerous potential problems with Access image handling and provides enhanced functionality, such as asynchronous decoding, EXIF viewing, resampling & thumbnailing, Zoom, pan and alignment control, rotation (including lossless jpeg rotation) and more.
Resources & LinksDBPix Image ControlDBPix Samples Pictures in Access Forms & Reports - Access 2003 OLE Object Photo Image & Picture Problems Access Image Database Techniques MS KB 123151: ACC: Why OLE Objects Cause Databases to Grow MS KB 103257: ACC: Reading, Storing, & Writing Binary Large Objects (BLOBs) MS KB 210486: ACC2000: Reading, Storing, and Writing Binary Large Objects (BLOBs) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
