How to display BLOB images in a MS Access Report?

[Adam Tippelt]

Hi all,

I'm trying to create a report that displays all relevant information per record. However this includes displaying a screenshot for each record.
Images are uploaded and stored as BLOBS. I've used this method as many discussions say it is the best option, due to bloating and path issues with the other methods. However to write the code for this myself is a little outside my knowledge, so I've had to use some found on the internet and alter it accordingly.

Everything regarding uploading the file to the database is working, but my problem now is getting to files to display in a report. I've tried using everything from object frames to activeX image controls, but I fear I do not know enough about what I'm doing here to make use of them correctly. Can anyone please offer any help on how to display BLOB images in reports?

Thanks.

Adam.

[ADezii]

@Adam - What I am about to propose is strictly Theory on my part, and I have absolutely no idea as to whether or not it will work. Since the BLOB Data is stored in a Binary Format, it cannot be displayed directly on a Report in any manner that I know of. This is what I am proposing:

1. Extract the Binary Data comprising the BLOB from the OLE Object Field and write it to an ADO Stream Object.
2. Save the contents of the Stream Object (BLOB) to a Temp File with a Primary Key as a Unique Identifier.
3. Load the Temp File into the Picture Property of an Image Control for each Record in the Record Source of the Report. This can be done in the Detail Section of the Report.
4. Before you even attempt this approach, you must know the File Extension associated with each BLOB (.bmp, .jpg, etc.).
5. If you do know the Extension for each BLOB, then I will be happy to test this Theory for you, just let me know.

[Adam Tippelt]

Well the hope was that it would handle as many file extensions as possible, at least all the major image extensions. From what you've said, do I assume different coding is required for each?

Also, would this method allow for a report to be auto-generated based on a query, with multiple images?
What I'm trying to create is like a "View-All" report that shows every record in one report, but each report includes at least one image, possibly more. Also these records are subject to change, so cannot have any hardcoded file paths.

Only reason I ask now is this methods looks a little over my head, and will clearly take me some time to do, so I want to know if it's worth it. (Of course all knowledge is worth learning, but I need to be specific at the moment :) )

The only extensions currently in the database are .jpg files, as that's what I got hold of first.

Cheers.

Adam.

[ADezii]

Give me a little time to see if I can come up with anything since this is an area that I never ventured into before. I'll get back to you on this matter.

[Rabbit]

First off. Why are you storing the image data in the database? Couldn't you have stored it on the file system and then just store the path to the image?

Second, if you don't know what type of image file it is, you need to store the type in another field so that when you extract it, you can append the correct extension. Otherwise, you'll need to look up the header information of the various image encodings to figure out what kind of encoding was used to create the picture.

[Adam Tippelt]

Various review articles I've read have suggested that storing the files as BLOBS is the most efficient way of using images with Access - the other methods appear to have issues such as bloating, and file paths doesn't have the integrity I want, should the original file be removed.
You make a good point about the file extension - while I know what it is, the system doesn't, so I'll go back and add code in for that.

I don't even know if what I'm after is possible. All I really know is where I'm at now, and where I want to be, but none of the methods I've tried have worked.

[ADezii]

@Adam - Rabbit's point is definitely valid concerning the File Type (Extension) which is exactly why I asked you this in the first place. Shortly, I'll demo some code on how to extract BLOBs to an actual File, then hopefully display these Images in an Image Control in a Report, but again File's Extension is needed.

[ADezii]

@Adam - the following Code will extract the contents of a BLOB Field into an ADODB Stream, write the Stream to a Unique File Name in a TEMP Directory under the Current Project Directory based on a Unique ID ([InvID]) and Extension ([sFileExtension]). These Files will then be dynamically loaded into an Image Control in a Report. Pay close attention to Code in the Click() Event of the single Command Button as well as the Format() Event of the Report's Detail Section. Make sure to set a Reference to the Microsoft ActiveX Data Objects X.X Object Library. I'll post the Code, but definitely download the Attachment to see what is going on.

Private Sub cmdTest_Click()
On Error GoTo Err_cmdTest_Click
Dim strSQL As String
Dim rstBLOB As ADODB.Recordset
Dim mstream As ADODB.stream
Dim strFullPath As String
 
'Create a Directory named TEMP if it doesn't exist under the Current Project Path
If Dir$(CurrentProject.Path & "\TEMP\", vbDirectory) = "" Then
  MkDir CurrentProject.Path & "\TEMP\"
End If
 
strSQL = "SELECT tblInventoryPics.* FROM tblInventoryPics"
 
Set rstBLOB = New ADODB.Recordset
rstBLOB.Open strSQL, CurrentProject.Connection, adOpenKeyset, adLockOptimistic
 
If rstBLOB.RecordCount = 0 Then Exit Sub
 
Set mstream = New ADODB.stream
    mstream.Open
 
With rstBLOB
  Do While Not .EOF
    mstream.Type = adTypeBinary
    mstream.Write rstBLOB.Fields("oPicture").Value          'Write to the Stream Object
 
    'Write BLOB to a File in the TEMP Directory under the Current Project Directory,
    'with a Unique Inventory ID (InvID) and Extension (sFileExtension)
    strFullPath = CurrentProject.Path & "\TEMP\" & ![InvID] & "." & ![sFileExtension]
    mstream.SaveToFile strFullPath, adSaveCreateOverWrite
      .MoveNext         'For each Record
  Loop
End With
 
rstBLOB.Close
Set rstBLOB = Nothing
 
'Open Report
DoCmd.OpenReport "rptInventory", acViewPreview, , , acWindowNormal
DoCmd.Maximize
 
Exit_cmdTest_Click:
  Exit Sub
 
Err_cmdTest_Click:
  MsgBox Err.Description, vbExclamation, "Error in cmdTest_Click()"
    Resume Exit_cmdTest_Click
End Sub

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
  Me![imgPicture].Picture = CurrentProject.Path & "\TEMP\" & Me![InvID] & "." & Me![sFileExtension]
End Sub

[Rabbit]

I'm not sure how it's more efficient to store image data in a blob. It's going to take up the same amount of space. And I would assume that retrieving the image would be much quicker on a file system than in a blob since you would have to write out the image data to a file before you can use it.

As far as data integrity goes, how is deleting the image file any different from deleting the image data in the blob? At least when it's in the file system, you might be able to retrieve it from the recycle bin. And if it's on a network location, you could retrieve the image file from a backup while to retrieve an Access database from a backup would roll back all changes made after the backup. Which would mean you would need to restore it to a different file name, find the record, and then import the blob back into the table.

Also, I would think that bloat would occur mainly on the Access end since there's not really a reason for bloat on a file system. In Access, when you delete a record, it doesn't free up the space in the database file unless you do a compact and repair. So you will end up with a database that constantly creeps up in size until you do a compact and repair. Also, since Access has a file size limit of 2 gigs, and image files can be rather large, you're going to hit this limit faster.

[ADezii]

As far as using the File Path approach, I was always under the impression that:

1. This technique cannot be used with Continuous Forms.
2. A fully qualified UNC Path is a strict requirement.
3. If you move the Images the Code will fail.
4. If the Images reside on a Server and the Folder containing them is not shared, the Code will fail.
5. If the Server is turned off, the Code will fail.
6. If you not have Read Permissions to the PC, the Code will fail.
7. etc...
8. After all is said and done, storing Images as BLOBs becomes the obvious choice for Image storage. Storing Pictures as BLOBs in the Database is the most efficient way on containing Image Data because the Picture data is stored byte for byte, exact size, with the Images reflecting their true sizes.
9. When BLOBs are stored in the Database with other data, BLOB and tabular data are backed up and recovered together and are synchronized, there are no File Paths to contend with, and no resultant Database bloating. Data consistency is ensured because INSERT, UPDATE, and DELETE operations occur in the same transaction. Separate security measures need not be created since BLOB and regular data coexist.