|
Question : storing jpg and retrieving on forms
|
|
i have a database and want to add a table which stores pictures... i tried some stuff used OLE object as data type did succeed in storing the image .. but i really don't know how to display that picture on the form or report .... and how does access really store the image.. does it actually store it or just stores the link... cause auto form didn't show the image till i double clicked it... and if i remove the original file from its location (the image) will it still be able to activate the image....
thank you
|
|
|
Answer : storing jpg and retrieving on forms
|
|
Hello groovy159
I stumble in because I would like to defend your position. You basically asked how the storage of OLE objects in tables works, and you got twice the answer "don't do it". Although I can confirm that this is in fact the best answer, you understandably feel that your actual question hasn't been addressed at all.
So, why is "don't do it" the generally accepted answer?
OLE object linking and embedding has been moderately successful between Office applications to allow for example an Excel table inside of a Word document. As Access is part of Office, it was natural to allow for OLE controls on forms and reports, and also to provide an OLE data type for tables. This means you can have a table containing linked or embedded Excel documents.
In practice, the only objects ever used in a table are plain BMP images (for example icons used in an application, or small ID pictures). If you store anything else than Office documents or plain Bitmap images, you run into problems.
OLE objects need an OLE server application. Instead of the file extention, each object gets an "OLE type", which is basically the application that was associated with the file on the computer where it was inserted. So that a JPG file could have a "MS Photo Editor" type on one machine, but a "Kodak Photo Viewer" on another, and a plain "Gimp 2.5" on yet another. Each time you need to view the object, Access will have to open a *dialog* with the OLE server. So it must be installed, and they need to be in friendly terms. Even between MS products, this is never guaranteed.
If your autoform did not show your JPG images, it is because you have: no appropriate OLE server on your machine, an OLE server that refuses to be embedded, a broken or outdated OLE server, a wrong file extension association, some software that Microsoft is offensive against ;)
So, this is what you have: a JPG file, embedded in some OLE mumbo-jumbo pointing to some other application registered as OLE server, and if you checked the "link to file" box the original path and name of the file. In that case, Access will attempt to "keep in touch" with the original and maybe consider uploading a new version if the original has changed. For linked files, it should also only store the "preview image" of the object and not the entire object. This is rather funny for JPG files, because the preview is much larger than the original.
"Don't do it" is thus the answer, unless you are willing to manage many "OLE server problem", "connection to OLE server lost", and "invalid OLE object" messages.
Most programmers prefer to keep their images outside of the database, for example in a special folder, and store only the file name (or the path and the name) in the database. This was Dmitry's anser. Marlind's is a slight modification (you can just click on the link to open the image, but you add the complexity of handling hyperlinks in case you want to move all your files to another folder.
If you really want to store images in your database, use long binary objects, in which you can store entire files. Exact copies of the files, that is, without OLE wrapping. To view them, you need to save them to a temp folder each time.
A good discussion of these three techniques (OLE, external and BLOB) can be found here:
Jamie's Software - Access Articles Handling Images with Microsoft® Access
http://www.jamiessoftware.tk/articles/handlingimages.html
Cheers!
(°v°)
|
|
|
|
|
