MDE packaging and Application distribution

[Guest]

I was not sure which group of Access to post this question, So I posted at 2
places.

I am completed my application, saved it as .mde, Now I want to distribute
this application to the users. Below question arises in my mind :

I am going to distribute to some user who dont have MS office installed on
their PC, so I should use the Package wizard from MS Office Developer. Now
the question here , does it will be a problem for the person who have MS
office Installed. Or it will run normal on both PC if or if not Ms office
installed.

Second question in my mind is that My application has a Menu's to open the
forms and report. Does it will show same on all computers, or it will be a
problem for menu's where MS office is not installed.

What are the precauation I should keep in mind while converting the mdb to
mde and then packaging for distribution, So that It should work on all
computer normal, wheter Ms office is insallated or not installed.

Please advise.

 

[Rick Brandt]

I was not sure which group of Access to post this question, So I posted at 2
places.

I am completed my application, saved it as .mde, Now I want to distribute
this application to the users. Below question arises in my mind :

I am going to distribute to some user who dont have MS office installed on
their PC, so I should use the Package wizard from MS Office Developer. Now
the question here , does it will be a problem for the person who have MS
office Installed. Or it will run normal on both PC if or if not Ms office
installed.

The best situation for installing the Access runtime is a PC that has NO version
of Access already on it. As far as I know the presence of Word, Excel, etc., is
not of prime concern.

The second best situation for installing the runtime is when the PC already has
the exact same version of Access installed because the installer is "supposed to
be" smart enough to not install the runtime if it see that the user already has
Access. As long as that works you should be ok. However if any of the files in
your install package (including MSAccess.exe) are newer versions than those on
the target PC the installer will replace them and (some) consequences could
result.

What you should try to avoid is installing the runtime when a completely
different version of Access is present. It's not a disaster, but the two
versions will mess with each other a bit. How big of a problem it is will
depend on the user and how much they are actually using the version of Access on
their PC. Many people have the full Office suite, but have never even opened
Access.

Second question in my mind is that My application has a Menu's to open the
forms and report. Does it will show same on all computers, or it will be a
problem for menu's where MS office is not installed.

For use in the runtime this has to be a completely custom menu/toolbar not just
a built in one that you have customized. There are two reasons for this.
Customizations to the built in command bars are local to the PC. They are not
stored with the file so if you give the file to someone else they will not see
those changes. An even bigger reason is that all of the built in command bars
are unavailable in the runtime environment. Those users will only be able to
use command bars that you have created from scratch.

Beyond that, they will be affected if any of the specific items on your bar do
"Office interaction" stuff. The spell check button for instance actually calls
the common Office spell checker (Access does not have its own) and the spell
checker is version sensitive. Items that are just manipulating local Access
objects should not be a problem.

What are the precauation I should keep in mind while converting the mdb to
mde and then packaging for distribution, So that It should work on all
computer normal, wheter Ms office is insallated or not installed.

The biggest thing (IMO) is to avoid the use of any additional library references
beyond the default ones that are present when you create a new blank Access
file. Additional references will lead to "DLL Hell" because you cannot be sure
that all users will have all of those libraries, or in the same versions, or in
the same locations (location should not strictly matter, but sometimes does).

The above is harder to troubleshoot if you distribute an MDE or if the PC is
using the Runtime since there is no access to the code window so you can check
the references. It would be a good idea to include a utility somewhere in the
app that will enumerate the references and show which ones are "broken". I
don't have the code handy, but there is a web resource that has example code for
doing this. Check "The Access Web" site.