Installing Access Run-time without Dbase

[Lisa]

Hi. (Access XP)

I have already installed my database on my clients
computer and now they need the run-time version of Access
for some of their computers.

The Package and Deployement information in my Developer's
Guide discusses packaging my dbase with the run-time but I
don't want to do this because I don't want to overwrite
the existing database. (Not a split database)

Can I create a disk that they could use to simply install
the Access run-time on their computers?
I think they might want to install the run-time version on
the server to let a few computers get at it - is this
possible?
If it could ask during installation to create a shortcut
pointing to the dbase on the network that'd be great too.

Thanks in advance
Lisa

 

[Paul Overway]

Nevertheless, if you already installed the database on their computers, and
they don't have Access installed, how do they run it? Also, unless the
server is a terminal server, the runtime must be installed on each client.

Are you saying that the MDB is deployed on a server and you don't want to
overwrite THAT file?

Distributing an unsplit Access database is bad practice. There is an
increased chance that the file will become corrupt and you are increasing
traffic on the network....plus your app will run slower. You really should
split it. Not splitting it will cause you a lot of work....just like you'll
need to do now.

At minimum, you'll need to run accessrt.msi and osp.msi on each PC that
requires the Access runtime and then setup shortcuts manually. Also, if you
are using any OCX/DLL, those will need to be installed manually.

 

[Lisa]

Hi.

They have a few licences for Access which they run the
database, but they don't want to have to buy more for the
people who just need to view the data occassionally.

Thanks for the details about the server - I will have to
ask them what they have.

Yes, the mdb is on the server and I don't want to
overwrite that file. The database is quite small in
number of forms/reports etc. so I hadn't bothered to split
it. They want to give people in another city (on their
network) access to the database, so I thought it would
just be easier to leave the database together so we didn't
have to worry about the front ends and getting them to the
other computers. Also, then as modifications are made, we
don't have to get the new copies to this other city.

If I create a FE/BE database, could I run the Packaging
feature and include just the FE which would already be
linked to the BE.

Can you tell me why a non-split database has an increased
chance of becoming corrupt?

I take it accessrt.msi and osp.msi are somewhere on my
developer disk and I would just put them onto a CD and
then run them at each computer?

No, I don't have any OCX/DLL - it's a fairly simple
database.

However, I do use the DAO library to manage recordsets -
do I need to install anything with the run-time for this?

Also, 1 dumb question, but I've never had to do the run-
time thing before...Are there NO menus or toolbars in the
run-time at all, not even the basics?

Thanks again.
Lisa

 

[Paul Overway]

Comments in-line

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Hi.

They have a few licences for Access which they run the
database, but they don't want to have to buy more for the
people who just need to view the data occassionally.

OK..that is why runtime is usually installed

Thanks for the details about the server - I will have to
ask them what they have.

Yes, the mdb is on the server and I don't want to
overwrite that file. The database is quite small in
number of forms/reports etc. so I hadn't bothered to split
it. They want to give people in another city (on their
network) access to the database, so I thought it would
just be easier to leave the database together so we didn't
have to worry about the front ends and getting them to the
other computers. Also, then as modifications are made, we
don't have to get the new copies to this other city.

If you have remote users opening the database over a WAN or dialup, you will
most certainly see a corrupt database at some point. If remote users need
this database, they should be opening it through Terminal Server/Citrix, or
the database should be replicated....but if replicated, it is even more
important that you split it.

If I create a FE/BE database, could I run the Packaging
feature and include just the FE which would already be
linked to the BE.

Yes....but make sure you are making an assumption that everyone's drive
mappings are the same. Use a UNC path.

Can you tell me why a non-split database has an increased
chance of becoming corrupt?

Any number of reasons really....but just a momentary loss of network
connectivity can cause corruption, and since EVERYTHING is being pulled over
from the server, there is alot more opportunity for something to go wrong.
Keeping track of multiple users writing to the same file is a complex matter
enough. It is managable with a split database, but multiple users opening
forms, queries, reports, etc adds more complexity to an already complex
situation.

I take it accessrt.msi and osp.msi are somewhere on my
developer disk and I would just put them onto a CD and
then run them at each computer?

Generate a package that includes the Access runtime....the files will be a
part of the package.

No, I don't have any OCX/DLL - it's a fairly simple
database.

Simple is good

However, I do use the DAO library to manage recordsets -
do I need to install anything with the run-time for this?

No...it is included

Also, 1 dumb question, but I've never had to do the run-
time thing before...Are there NO menus or toolbars in the
run-time at all, not even the basics?

No...you have to create your own. And your app really needs to be
bullet-proof in respect to error handling. Avoid macros to the maximum
extent possible (autoexec and/or autokeys are ok...nothing else)

 

[Lisa]

Thank you for all of your advise and information.
I feel much better about tackling this situation now.
Lisa