Pros and Cons of Office Developer 2K

[Fysh]

I am trying to get a handle of the Pros/Cons of using a runtime Developer
program so I can explain it to my boss. I have several DB programs in the
past, but I am looking at using the office developer to create a runtime of
future versions. I have been hearing that using this program can interfere
with other programs and could cause a problem with some of the DLLs. Can
someone tell me if this is so and tell me the pros/cons of using such a
program rather than just keep creating software with the regular Access 2000
program? I really appreciate this, thanks.

 

[Rick Brandt]

I am trying to get a handle of the Pros/Cons of using a runtime
Developer program so I can explain it to my boss. I have several DB
programs in the past, but I am looking at using the office developer
to create a runtime of future versions. I have been hearing that
using this program can interfere with other programs and could cause
a problem with some of the DLLs. Can someone tell me if this is so
and tell me the pros/cons of using such a program rather than just
keep creating software with the regular Access 2000 program? I
really appreciate this, thanks.

Distributing a runtime version of your app is "relatively" painless as long
as you only install it on PCs that have NO version of Access already on them
(including other runtime apps in different Access versions). In a corporate
environment where what software is installed is somewhat controlled this can
be achieved pretty easily. If you need to distribute to PCs of unknown
configuration then you are sure to run into problems.

In that situation I would recommend having a version of the app on your
distribution CD in all versions of Access that you want to support as well
as the runtime in whatever version you buy. Then users who have Access
simply install the appropriate file and only those who need the runtime
install that.

 

[Fysh]

Thanks for the response, what could go wrong if you use the run time version
on a system with Access already on it or for that matter other runtime
version? I am just trying to get to some answers that I could discuss with
the boss because of the sensitivity of some programs on their machines. We
have several places that are not computer literate and I would hate to create
some problems that I could forsee before hand. Thanks,

 

[Rick Brandt]

Thanks for the response, what could go wrong if you use the run time
version on a system with Access already on it or for that matter
other runtime version? I am just trying to get to some answers that
I could discuss with the boss because of the sensitivity of some
programs on their machines. We have several places that are not
computer literate and I would hate to create some problems that I
could forsee before hand. Thanks,

Whenever Access is launched it registers itself as the default executable
for all files of type (MDB, MDE, MDA, etc..) and makes other registry
changes. So if you install your runtime of Access 2000 on a PC that already
has Access 97 then after using your app for the first time the user will
find that double-clicking any Access file will cause it to open (or at least
attempt to open) with your runtime Access 2000 executable instead of his
version of Access. If he opens Access 97 first and then opens files from
there he'll be ok, but he will have to live with never opening an Access
file by double-clicking.

In some cases the two different versions will cause conflicts about the
location of the default workgroup file and you will get errors from that.

Some of these issues can be overcome by buying SageKey scripts (in addition
to the developer's tools) that make your runtime installation more
independent, but that is a few (several?) hundered more dollars you have to
spend.

Don't get me wrong. Multiple versions of Access can co-exist (I have four
versions on my PC right now), but it does introduce "issues" and some of
your users might not like to find out about them after they have installed
your app.

 

[Larry Daugherty]

Hi,

You might do better to back up and ask the larger question in terms of what
it is you hope to achieve versus the cost of doing so. Cost may include
factors other factors as well as money.

What you gain by providing runtime installations to your target users is
that they are not required to have that version MS Access on their machines
to run your application. If there are other needs that require them to
have the current version of Access then you don't gain anything. If your
organization buys bulk licenses for Office and there are other people in the
organization that need Office Professional then you have another trade-off
to consider. It doesn't take too long for the cost of retail copies of
Office Pro to start catching up with the difference in bulk licenses between
Office Standard and Office Pro.

There is always *some* risk that your runtime installation could cause
problems. There are a couple of Access newsgroups devoted to developers
toolkit issues. You should lurk them to gather some insight. I believe
that Tony Toews has gathered some "runtime" lore on his site. The URL is in
his signature line.

If your concern is in protecting your code then convert to MDE before
distributing to your users. You should do that anyway.

HTH

 

[Fysh]

Thanks, that helps.

Whenever Access is launched it registers itself as the default executable
for all files of type (MDB, MDE, MDA, etc..) and makes other registry
changes. So if you install your runtime of Access 2000 on a PC that already
has Access 97 then after using your app for the first time the user will
find that double-clicking any Access file will cause it to open (or at least
attempt to open) with your runtime Access 2000 executable instead of his
version of Access. If he opens Access 97 first and then opens files from
there he'll be ok, but he will have to live with never opening an Access
file by double-clicking.

In some cases the two different versions will cause conflicts about the
location of the default workgroup file and you will get errors from that.

Some of these issues can be overcome by buying SageKey scripts (in addition
to the developer's tools) that make your runtime installation more
independent, but that is a few (several?) hundered more dollars you have to
spend.

Don't get me wrong. Multiple versions of Access can co-exist (I have four
versions on my PC right now), but it does introduce "issues" and some of
your users might not like to find out about them after they have installed
your app.