Incompatibility between MS Access Ole server and Adobe Reader

[Sandro Arena]

I made an Access database where you can insert an Ole object such a pdf file
that is showed as icon into the records . If you click over the control it
opens the adobe reader to show the file. It worked untill I used Adobe Reader
6.0 . When I updated Adobe Reader with a newer version of Adobe Reader 6.0
the Ole server of every version of MS Access stops to work. How is this
possible? Once it is installed Adobe Reader it isn't possible to use the Ole
insert object into an Access Database. I have tried with differents
computers, with differents Adobe Reader free and full programs, with
different version of Access, with different operating system (XP and Vista)
and it's the same. When you create a new record and insert a pdf file the Ole
Access server stops to work and You can't insert any kinds of Ole object, MS
Ole object too.

Is there someone is able to help me? Is it possible that nobody know this?

Thanks

 

[Arvin Meyer [MVP]]

I have found that Adobe is unreliable, and inconsistent in its support of
its own products. I prefer a different reader, FoxIt which is significantly
faster and more stable than Adobe Acrobat.

http://www.download.com/Foxit-PDF-Reader/3000-2079_4-10313206.html

 

[Sandro Arena]

I' ve tried every pdf reader but it's the same thing. I've reinstalled adobe
6.0, I' ve reinstalled MS Office 2003 and 2007, I've Installed every update
possible but the problem remain. I Am thinking that MS Access is ridiculous.
I've wronged to use Microsoft. It's absurd that into a database you can't put
an ole object.

 

[Albert D. Kallal]

I' ve tried every pdf reader but it's the same thing. I've reinstalled
adobe
6.0, I' ve reinstalled MS Office 2003 and 2007, I've Installed every
update
possible but the problem remain. I Am thinking that MS Access is
ridiculous.
I've wronged to use Microsoft. It's absurd that into a database you can't
put
an ole object.

The problem is things broke when you installed the new version of Adobe.
Adobe issue updates every month or quite frequently as they come out with
new versions of their product, especially the reader.

You were NOT upgrading MS access that causes things to break, it was
somebody else's product that you were upgrading is when all hell broke
loose.

However, I don't want to stand here and try and pass the buck. All I can say
is most developers will tell you who the trying to embed some of these ole
products into MS access becomes really difficult especially when those
manufactures of the product frequently update their software. You can never
be sure that the next version they issue will work correctly, and it'll
break your software. I can't stress once again, that it was not you
upgrading MS access that broke things here, it was in fact upgrading another
product that you're relying on. it seems to me was up to that vendor to test
an insured of the product would not break your software when they installed
it.

The simple solution this case is simply to store a path named to that pdf
document, and use the following command to launch it. Virtually all the
developers have done this for years and years, and no matter what version of
Adobe you use, no matter what kind of pdf viewer, you complete 100%
eliminate the problems you having.

I strongly recommend that you don't imbed the file as an ole object. Simply
store the path name to the file, and then place a button on your form to
view the file. The code behind the button will be:

Application.FollowHyperLink "path to pdf file"
or, assuming you're storing the path in the field name, the go:

Application.FollowHyperLink me!MyFieldWithPathName

So either you do the above, or you keep 100% keep a consistent software
environment, and use your original setup that you had that was working.
Simply do not upgrade beyond adobe 6.0. The problem is that the Adobe
wants to upgrade itself all the time, and therefore you risk breakage again.

As a software developer you're simply going to have to make some compromises
here, and make some decisions to control what pieces of software you're
going to install on that machine. If you don't have that controll over the
software, then you simply can't risk using ole inbedding of objects,.

The reason why you can risk this is because those other vendors are
upgrading their products all the time.

Remember, it was not the upgrading of MS access that broke things here, it
was the fact that you upgraded from something that was working (adobe 6) to
a later version that broke.

I suppose you could check with the Adobe newsgroups and forms to see what
they suggest (and I suggest you time how quickly you get a response from
them, as compared to how much support and responses that you've gotten here
so far).

It seems to me that you should blame the people that changed something here,
not the people that didn't change anything at all here.

 

[Paul Shapiro]

I agree completely with Albert, but would offer one additional possibility.
If saving the pdf in the db is important, and you don't want to keep the pdf
in the file system, you can still open it without using OLE. Save the stored
pdf from the db to a temporary file, and then open it with the method Albert
described:
Application.FollowHyperLink "path to pdf file"
When the user closes the document you can delete the temporary file.
Personally I would save the pdf in the file system. You could create and
maintain a document library folder beneath the db folder.

 

[David W. Fenton]

I agree completely with Albert, but would offer one additional
possibility. If saving the pdf in the db is important, and you
don't want to keep the pdf in the file system, you can still open
it without using OLE. Save the stored pdf from the db to a
temporary file, and then open it with the method Albert described:
Application.FollowHyperLink "path to pdf file"
When the user closes the document you can delete the temporary
file. Personally I would save the pdf in the file system. You
could create and maintain a document library folder beneath the db
folder.

Doesn't the OLE data type enclose the file stream in a wrapper that
tells OLE what to do with it? If that's correct (and I believe it
is, at least in a general sense, i.e., the raw contents of the OLE
field are not byte-for-byte identical with the data stream of the
corresponding file), then would it not be better to store the file
in a plain BLOB field, and then write *that* out to a temp file?