We help IT Professionals succeed at work.

Access package datatype (linked picture) - Can I extract the file path to the link?

blcote
blcote asked
on
Medium Priority
550 Views
Last Modified: 2009-12-16
I have an existing Access 97 application that needs to be upgraded to Access 2003 and moved to a different server. Because of the age, it is using the older  Microsoft Image OLE Server from Eastman / eiStream. When adding a record on the old system, the user would right mouse on the Bound Object Frame, and select menu item Package Object > Edit Package. This opens the Object Packager dialog. The user selects File > Import which opens a file selection dialog. The user selects the file, and exits the Object Packager.

I still can't figure out if it is saving a link or embedding the object, I think it is the latter. When I first opened the application, the IMBTHUMB.OCX was missing. When double clicking on the bound object, a dialog would open saying it could not find the image file and gave a path from the old server. All the images (.JPG) are in a directory.

All the users want to know is if the JPG file exists for each record. Because the database column is of datype OLE Object, and the ObjectPackager was used, I can't extract the filename.

What I want to do is -> write code in Access that I can launch from a button that will get the JPG object from the database and somehow extract the filename or pathname. I can then store this name in the database in a String column, and modify the form to show the JPG using Microsoft Picture Viewer (outside of Access). I might be able to programmatically use the ObjectPackager, but I don't know what library I need to include, or if it even has an API.

Thanks!
Brad
Comment
Watch Question

CERTIFIED EXPERT
Commented:
To get the files and links out:
http://www.lebans.com/oletodisk.htm

To view images stored outside of Access:
http://www.thenelson.name/#LinkedImageDemo

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Commented:
Hello,

I'm afraid I'm the bearer of bad news. I did an extensive search a while back about the object packager and I couldn't find any way to manipulate the packages programatically, neither at Micro$osf, nor anywhere else on the Internet. The more I learned about this #### piece of ####, the more I hated it, to tell the truth.

Best bet: hire a student who will open each package manually, save the file and store the path in the table. You can create a form to help him/her do the last part, but that it.

Of course, do a search again. Someone might have hit a database so big that it was worth the trouble to write an extraction tool.

Good luck!
(°v°)

Commented:
Good links, Nelson (your link library is impressive), but this doesn't address the real problem: the Object Packager...
(°v°)

Author

Commented:
The ExtractInventoryOLE.zip has *EXACTLY* what I needed - I can't believe it! I post a question at 5 PM on a Friday night and get multiple answers in 15 minutes, one of which also had a working program that dumped exactly what I want into a table!

Most Excellent - I wish I had selected the highest point number - Thanks harfang!

Brad

Commented:
Wow. Does this actually extract the files from the package? This is great news!
(°v°)
CERTIFIED EXPERT

Commented:
You're welcome.  Glad to help and thank you very much for the points with "A" grade!

Happy Computing!

Nelson

harfang,
Yep, Steve proved his genius again.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.