Thoughts on Runtime vs Access

[Guest]

I want to distribute my application commercially with as few hassles
(headaches) as possible. The db will be distributed as an MDE. I look to the
experts on whether going the runetime route is better or is it less of a
headache to simply distribute as an Access file? Many Thanks!

 

[Rick Brandt]

I want to distribute my application commercially with as few hassles
(headaches) as possible. The db will be distributed as an MDE. I look
to the experts on whether going the runetime route is better or is it
less of a headache to simply distribute as an Access file? Many
Thanks!

Well if you are going to make having an appropriate version of Access being
installed a requirement of your application then certainly just distributing an
MDE is easier than creating a runtime installation.

How many people do you think are going to have a version of Access that will run
your file? That is certainly going to cut down on who can use it.

 

[Guest]

Well maybe I'm wrong but here's my thought. The application is for
businesses, strictly. I haven't seen a business yet that does not have an
Office installation somewhere. Additionally, my app does not need to be
shared across a business. Most business users only need one instance of the
application. Since Access comes with Office, the majority of potential users
in the business world have Access. If for some reason they don't and they
really want my app, then they have to buy a version of Access. Do you think I
am shutting out too many potential users with this train of thought?

 

[Guest]

from Rainbo01 Hong Kong

use Setup Package!

for each Access Version has different version for setup package

OfficeXP---->OfficeXP Developer Edition
Office2003----->Microsoft Office Access 2003 Developer Extensions(one part
of Visual Studio Tools for Office 2003)

"MBoozer" 來函：

 

[Brendan Reynolds]

You seem to be forgetting that the Standard and Small Business editions of
Office do not include Access.

Runtime deployment is, unfortunately, often a necessary evil.

One question to ask yourself is, if users have to buy a copy of Access to
use your application, how much *relative* difference will that make to the
cost of your application? If your application sells for 1000 USD per user,
then the relative cost is about 10% if they qualify for an upgrade. If your
application sells for 100 USD per user, then the relative cost is about 91%.

(The above calculations are based on a price of 90.99 USD for an upgrade
copy of Access 2003, which was the price advertised at www.amazon.com at the
time of writing).

 

[Ken Snell \(MVP\)]

And one other thing to keep in mind, in conjunction with Brendan's astute
observations:

Runtime ACCESS does not exist well side by side with full installation of
ACCESS. Many conflicts can arise. So if your customer has full ACCESS, you
may not want to use runtime for that customer; otherwise, go with runtime.

 

[Ron Weiner]

I agree with Ken, it is a zillion times easier to deploy your application
without the runtime. If our clients have enough copies of Access we use
'em. When they do not have enough copies we selectively install our app
using the runtime.

We also develop our applications exclusively in Access 2000 so to make them
compatible with all Access Versions from 2000 and higher. We no longer
support Access 97 and to date have not seen this to be a problem for our
clients. Right now I would estimate the 80 to 90% of our clients (mostly
Public Schools) are using the full version of Access with our apps.

The biggest complaint we have had with the runtime version was its lack of
spell checking. We got around this complaint by Automating Word (using late
binding) to do the spell check in the runtime installs. Virtually 100% of
our clients have some version of MS Word installed.

Frankly, if I were to look at developing our main application today,. as the
back end is already in Sql Server, I would not consider Access for the front
end. I'd go with some web based technology (Classic ASP or .NET). Though
is tougher to develop in these environments (Access is a DREAM for
developers), and less rich of an experience for the user (but getting better
all the time). It is compatible with many more potential customer desktops,
and at least a zillion times easier to install and upgrade.

One of these days real soon I'm gonna rewrite the whole shebang..... Yea
any day now... Real soon.

 

[Brendan Reynolds]

Funnily enough, though, the more time I spend writing ASP.NET code, the more
I begin to think that perhaps the Access runtime wasn't quite so bad as I
used to think it was! :-(

Having spent a whole day wrestling with something that would have taken
about five minutes in Access, I have been known to mutter: "Come back
Access - all is forgiven!"

 

[Guest]

Thanks alot everone! You've given me direction. I think we will offer the mde
in 2000 format for all Access installs and offer the runtime (created in
2000, 2002 and 2003) for those who don't have access. (And whoever thought
distributing software was easy?). We'll have to leave 97 behind.

 

[Rick Brandt]

Thanks alot everone! You've given me direction. I think we will offer
the mde in 2000 format for all Access installs and offer the runtime
(created in 2000, 2002 and 2003) for those who don't have access.
(And whoever thought distributing software was easy?). We'll have to
leave 97 behind.

Why have more than one runtime version? If they have NO version of Access
installed then you can always use a single version. In that case 2000 will work
on more PCs then either 2002 or 2003 so why not go with that?

 

[Guest]

Thanks Rick. I thought you needed the right version runtime for the same
operating system. If 2000 runtime will work on xp, etc, then I think I have
it. Offer mde in Ac2000 and make a 2000 runtime version that will work on
majority of machines. Thanks.

 

[Rick Brandt]

Thanks Rick. I thought you needed the right version runtime for the
same operating system. If 2000 runtime will work on xp, etc, then I
think I have it. Offer mde in Ac2000 and make a 2000 runtime version
that will work on majority of machines. Thanks.

The Office version has little to do with the OS version except that Office 2002
needs Windows 98 SE or higher and Office 2003 requires Windows 2000 SP3 or
higher. Office 97 and 2000 should run on any version from 95 on up.

The same rules for Office apply to the Access runtime.

 

[Guest]

Thanks Rick. I understand.

 

[Guest]

One last point of order. If I distribute a runtime created in Ac2000, it
"should" run on all OS including 98, 2000 and xp?

 

[Brendan Reynolds]

It is best to create the runtime package on a clean install of the earliest
version of Windows you intend to support. A runtime package created on a
clean install of Windows 98 should install on Windows 98, 98se, 2000 and XP.
But a runtime package created on a later version of Windows may not install
on an earlier version. This includes service packs - a runtime package
created on Windows XP SP2 will not install on an unpatched installation of
Windows XP.

Windows ME further complicates the situation. Although Windows ME was
released after Windows 98, we found that our runtime package created under
Windows 98 did not always install on Windows ME, and we had to create a
separate runtime package, created under Windows ME, for users of that
version of Windows.

If you don't have a half-dozen spare PCs lying around that you can use for
creating and testing packages under various flavours of Windows, Virtual PC
can be a life-saver ...

http://www.microsoft.com/windows/virtualpc/default.mspx

The SageKey tools also help to avoid many problems ...

http://www.sagekey.com/

 

[Ron Weiner]

Although it has been a while and my memory aint what it use to be, but we
had MANY problems getting clean installs with the Access 2000 runtime
package. We moved to the 2002 runtime, got a good build and have used the
same cd ever since. Our software was designed to be self updating, so all
we need is to get a runtime installed (even though the Access program that
gets installed with it is a few years out of date), and the software updates
itself the first time the user attempts to use it. I fear should we ever
loose that CD we could be in trouble.

The Win 98 second edition limitation is not much a barrier for us, as our
software just barely works on a machine with 64mb ram anyway. It ran so
slow on a box with 64mb of ram, we have never bothered to test on anything
with less memory. We recommend to our potential clients that the desktop
have minimum 128mb ram which typically eliminates anything that is not Win
2K or better. We do have a few scattered Win98 and Win ME users out there
but the vast majority have Win 2K or better.

If I were you I would set my customers expectations right up front. Test
your software on down level OS's and low memory configurations before you
give the customer a blanket statement that the software will run on anything
that is win 98 or better. Because when the customer installs your
masterpiece on that 8 year old Dell with a PII 400, 32Mb ram and a 10Bt NIC
and starts calling with support problems, you will have to go into "Holy cow
how did I get myself into this predicament" mode. I have been there, it
aint fun! :-(

Good luck with your project.

 

[Ken Snell \(MVP\)]

Also, the runtime must be patched/upgraded with all ACCESS and OFFICE
updates on the client's PCs after it's installed. You cannot patch/upgrade
the runtime as part of its preparation. So the client also will need to be
told to do those updates after installation.

 

[Rick Brandt]

It is best to create the runtime package on a clean install of the
earliest version of Windows you intend to support. A runtime package
created on a clean install of Windows 98 should install on Windows
98, 98se, 2000 and XP. But a runtime package created on a later
version of Windows may not install on an earlier version. This
includes service packs - a runtime package created on Windows XP SP2
will not install on an unpatched installation of Windows XP.

Windows ME further complicates the situation. Although Windows ME was
released after Windows 98, we found that our runtime package created
under Windows 98 did not always install on Windows ME, and we had to
create a separate runtime package, created under Windows ME, for
users of that version of Windows.

If you don't have a half-dozen spare PCs lying around that you can
use for creating and testing packages under various flavours of
Windows, Virtual PC can be a life-saver ...

Just curious Brendon...Are these issues you cite with the 2000 runtime (or
higher)?

My development PC over the last several years has gone from Win95 to NT4 to
2000 Pro to XP Pro and throughout all of those changes I have been creating
and distributing 97 runtime packages that run on just about anything.

 

[Brendan Reynolds]

Access 2000. I'm quite surprised that you haven't encountered similar issues
with Access 97 runtimes, but then I haven't deployed any Access 97 runtimes
for some years now. From what you tell me, perhaps I should have stayed with
it!

 

[Guest]

Holy Cow! Alright, here's the beef. I have plenty of old pc's lying around. I
will take one, reformat the drive and do a clean install of 98 withOUT any
service packs. Then I will install office2000 w access 2000. If I can only
find that %$# Office2000 Developer CD I once had. At any rate, shoudl I do
the office2000 service packs or just go with the original install of
office2000?