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.

[Rabbit]

1. What do you mean by it can't be used with continuous forms? Do you mean if you wanted to display the picture? Doesn't the same problem exist for trying to display the blob data in a continuous form? You would have to export the blob data into an image file and then set the property of the image control. I don't think that would work on a continuous form either.
2. I don't see a problem with storing a relative path with the images in a folder where the database is stored.
3. Which is why I would use a relative path. If you move the images, you would move the database with them I would assume.
4. If the images need to be shared, then so does the database. Keep them in the same parent folder and the permissions will be inherrited.
5. I would assume everything would be kept on the same server.
6. See number 4.
7. etc.
8. Actually, it's not byte for byte. At least not according to this article by Microsoft. http://office.microsoft.com/en-us/ac...005280225.aspx. Apparently, Access will create additional bitmaps that go along with each image you store in the database. So you're storing more than just the file.
9. I think the second half of that statement could be reasons to use a blob over storing a path. Whether or not it's enough to justify it, I don't know. I do, however, contend that there will be more bloating in Access. Not just due to the article linked above, but because Access doesn't free up unused space in the database file until you run a compact.

[Adam Tippelt]

my point was that if the user deleted the original file, unaware that it was still being used by the database, then it could cause problems.
Yes I agree that bloat isn't properly handled until the database is compacted, but surely it makes sense to try and prevent it in the first place (or at least restrict it's level of growth) instead of fixing it later?

I was under the impression that the 'creating additional bitmaps' problem comes with just straight up embedding images in an OLE Object field. This is why I mentioned bloating, as the bloating is caused by the additional creation of bitmap images.
BLOBS are stored in Binary Large Data fields, and don't create bitmap images - probably the reason why you can't just straight link BLOB images to bound object frames.

I could be wrong, but that's what I've read.


Thanks very much for the code ADezii, i'll see how I get on with it!

[Rabbit]

Accidentally deleting of files could be a problem but so could accidentally deleting the data in the blob. I just think it's much easier to recover a deleted file than blob. Also, the user shouldn't be in that folder changing stuff anyways.

You really can't prevent bloat in Access without a compact. You said that there is bloat with the other methods like the file system method. But I don't see how there's any bloat by storing images on the file system. I imagine there's more bloat by storing it in Access.

The OLE Object field is a BLOB field. You can store byte for byte only if you do all inserts and updates through VBA coding. Otherwise, it will create the bitmaps.

How big is your data set? Access has a limit of 2000 megabytes. Assuming an average picture size of 1 megabyte and assuming you're using VBA to insert and update the BLOB data, you're looking at a maximum of 2000 records. Not counting the size existing forms, reports, other tables, etc. So if you may hit 2000 records at some point, it's not going to work.

But even assuming you only have 100 records, every time someone views the report, it has to read 100 records worth of images, write 100 files, and read those 100 files into the report.

[Adam Tippelt]

Right I've managed to successfully implement your code onto my db, and it does what it should. I do however have a couple of queries:
Should the TEMP folder not be deleted once the database is closed? In a multi user environment would it cause problems if they were deleted while a user was still using them?
Should there be any bloating or performance issues related to doing this? Just by creating the report and opening it, my database has shot up from 6188kb to 13768kb, and my whole machine was suffering from a bit of lag after doing so. Performance quickly went back to normal, but the size issue still remains, even after a compact.

[Rabbit]

From the look of ADezii's code, once the user is finished with the pictures, it doesn't matter what happens to the temp folder and its contents because the folder will be recreated if it's not there. The pictures will be recreated each time.

If a user was looking at the report and the files get deleted, then those pictures that had not yet been rendered by the report would be missing from the report.

The lag you experienced is due to when you view the report, it has to read the blobs, write the files, and load those files into the report. The bottleneck is most likely the writing of the file. You can mitigate this using a RAID array of hard drives.

If you will be using this in a multi-user environment, I suspect there may be write conflicts if two users tries to view the report at the same time and it tries to write to the same file at the same time. One of the users will get an error.

[ADezii]

You are quite welcome, good luck Adam, and let us know if you need anything else.

[ADezii]

@Adam - Here is a Demo DB on BLOBs that you may find very interesting, and well as very informative in your case. The Base Code is by Alan Warren, but I made several modifications to it, and use this DB as a Template anytime I am involved in a Project that comprises BLOBs. Enjoy and have fun...

[Adam Tippelt]

If it's a split database would that not eliminate the conflict problem?



Thanks both for the information, and cheers for the file ADezii i'll keep that in my collection. :)

[Rabbit]

If the database is split, and each user has the front end on their computer, then there would be no conflict. However, you indicated that there's a possibility someone else might delete the images while someone was viewing the report. This suggests that the front end will be stored on the network and shared by the users. In this case, there is the possibility of conflicts. An alternative then, is to change the code so that the image folder gets created in the user's profile folder.

[Adam Tippelt]

Thanks, but I am not looking to buy or download anything, as that is not a viable solution for the situation.