Microsoft access database was never really designed to handle images the same way other Office applications do and maybe it was deemed as bit of an afterthought.
Different versions lead to different challenges and the latest version (2016) still have issues ending sometimes up with invisible images on those forms and reports. This is further complicated by having a 32-bit version of Access 2016 (16.0.4229.1024) and perhaps not the 64-bit version installed but that may not be a good enough reason to use the 64-bit version at all (unless of course images are your thing!).
In Access, images should appear properly but some simply do not. The original Images used this application was the BMP file format and they continue to properly show up however, other graphic types such as GIF, JPG and PNG formats may end up as a blank non-starter!
One thing you could check out is the database’s Picture Property Storage Format when the picture was added to the form or report. This can be found under the ‘Access Options’ setting for the Current
There two options are:
If the image is added when the above option is set to the second option (Convert), the non-BMP graphics do not appear in the 2016 version.
The recommended approach here for a non-visible image is to check the above option and choose the older (second version) to see if it makes a difference.
I would recommend actually removing and re-inserting the image again, save and run the form or report. Repeat the same steps again but choose with the first option instead (and it should really be this option in an ideal world).
Still having problems?
As with earlier version of Microsoft Access, there are other techniques available to handling image files in forms, reports as well as tables:
Store the image in an OLE field and use a bound object frame to display the image.
Store the path to the image in a text field, using an image control to display the image.
Store the image as a binary large object bitmap (BLOB) in an OLE field, extract the image when required and use an image control to display the image.
Again, no method above is perfect but the first option maybe the easiest to add but can be the most problematic too as not everyone will want to use OLE due to bloated file size and memory allocation it uses, the old MS Paint application to create and save images and server side processing errors when displaying such images really do not help.
The second technique is generally regarded as the preferred option and is also fairly easy to implement. For a table, the path to the image is stored in a text field and the image is displayed using a standard image control object to the form or report. However, a bit of VBA code is required to set the image control’s “picture” property to the path that is stored and keeps the database size to a minimum, increasing the overall performance of your MS Access application.
The VBA code will need to call the object name like for instance your named image control called ‘MyImageCtrl’, and one of its properties called ‘Picture’ and then set it to the string (text) full path like (example only):
But it’s not a perfect solution either leaving it and will require more VBA code to handle multiple records which may have individual images too (not covered in this blog) leaving with the last option being the trickiest to complete as it also requires VBA code and has the advantage of storing images inside the database, meaning that password protection is possible and also avoids the bloated files first mentioned. It will require the use of either DAO or ADO to collect the image file and read it into the OLE field (and is not covered here in this blog – please do some further research on this).
So, images may not be a perfect fit and web based applications which Microsoft access database also can use maybe a good balance and workaround.
It still requires good form and report designs will complement your images but don’t focus on these images too much and be distracted by the real reason and power that Microsoft access database offers.