Running Access front end from a server

[Bobk]

I started developing what was to be a small Access system designed to monitor
production in a small manufacturing plant. Initially, I split the database
and placed the back end on the server. Each of three workstations had full
versions of Access 2003. I wrote the code and then installed it on each
workstation thinking this would be the most efficient way to set things up
and would minimize the load on the server. The only inconvenience was having
to reload new code on the three workstations as the application was being
developed. The application has been very successful. We now have twelve
workstations, so any changes must be loaded onto twelve workstations -
terrifically inefficient.

I have another application at a different site where I have split the
database which resides on the server. I also have a copy of application
source code on the server and have shortcuts on each of 4 workstations to the
source code. Each of the workstations have full versions of Access. This
seems to work ok. I am wondering if this would work ok with 12 workstations?
The software maintenance issues disappear, but does this eventually bog down
the server? And - is there a limit to the number of workstations this method
supports?

Any suggestions on how to do this correctly?

 

[Dominic Vella]

Having a centrally located 'Back End (data)' is a great idea. Multiple
links to front end though could cause trouble for you in the future.

It is best if every workstation have it's own copy of the front end and have
them link to the back end.

Advantages:
* System works much faster and with less chance of corruption

Disadvantages:
* Keeping each workstation up to date usually requires manual upgrading.
* Difficult to maintain security

Trust me, advantages outway the advantages!!

 

[Albert D. Kallal]

I have another application at a different site where I have split the
database which resides on the server. I also have a copy of application
source code on the server and have shortcuts on each of 4 workstations to
the
source code. Each of the workstations have full versions of Access. This
seems to work ok. I am wondering if this would work ok with 12
workstations?
The software maintenance issues disappear, but does this eventually bog
down
the server? And - is there a limit to the number of workstations this
method
supports?

It is really more than the issue of just bogging down the server at issue
here. The issue is what happens if one workstation has some problem or locks
up the front end, or even damages the front end. Now you have 12
workstations down? You are opening yourself up to a situation that one user
has a slight problem with the front end and does something to it, now all
users are locked out are going to have the same problem.

Imagine for a minute if one user new whole building had a problem with word,
then every other employee in the building had to stop using word because are
all sharing the same copy? You've always installed applications like word on
each computer. You've always installed applications like excel on each
computer, now the fact that you're building applications why would you
change the scenario? There's a grand canyon of difference between a data
file that word, excel or your application consumes. You can certainly share
and place the data part of your application on the server, but the code and
user interface part, or what we call an "application" needs to be installed
on each computer like you've always done.

The real question comes down to how reliable do you want your setup to be.
Allowing multiple uses into the front and simply reduces the stability and
reliability of your application.

I explain the issues of splitting in following article of mine, I not only
tell you the split, but explain **why** you split and I think why's are more
important than just telling you.

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

So while it makes no sense to pull the application of word across a network,
or excel accross the network, or in your case your application across the
network, the issue really comes down to **reliability** and **stability** of
your application.

It's very much the same as an auto Mechanic telling the company that they
don't have to change the oil in their cars, it might not cause a problem
right away, but if overtime all vehicles start breaking down, the customers
confidence in you as a Mechanic is going to be severely damaged.

The same thing goes for your application, the more instability and problems
you have, the less they will view your application something they want use
in the company. Once you break down the confidence they had, it's very
difficult, in fact in some cases impossible to win back the confidence that
they had in you. At the end of the day it's really your reputation as a
developer that's on the line here. You don't wan to onsciously do something
that you know is going to reduce the stability of your application.

You don't want to have the people using the application saying well this
guy's not doing a very good job because is not very stable. they will start
to say maybe we should get rid of him and get a real developer that knows
what he's doing. I'm not try to criticize you here, I'm just try to point
out the issue of reliability of your applications is a really important
factor in terms of how they view your software. You might have the most
perfect user interface and the BEST code in the industry, but if you have no
reliability in your software, they will view your software as being poorly
built.

As for the updating issue, you can roll your update system in about an hour
or so of your time (that is what I did).

However, even better is Tony's free front end updater here:

http://www.granite.ab.ca/access/autofe.htm

So at the end of the day there's really no excuse for any person not to roll
their own little update system, or better yet use something that is really
good and freely available such as Tony's updater.

There's also a bunch of code for FTP and downloading libraries that you can
find at the following link if you wanna cobble together in a few hours a web
update system:

http://www.mvps.org/access/

For example here's is a series of screen shots that I use for some fo my
customers to update my access applications:
http://www.kallal.ca/ridestutorialp/upgrade.html

the above "about" screen and the progress bar is even ms-access code....

 

[Arvin Meyer [MVP]]

Stop! Don't even consider sharing a front-end. The chances of corruption are
ridiculously high when compared with separate front-ends. To make your
upgrades easier, place a copy of the latest linked front-end on the server
and have each user download it. To make it even easier use my free version
tool:

http://www.datastrat.com/Download/Starter.zip

or Tony Toews tool:

http://www.granite.ab.ca/Access/autofe.htm

If your users are even slightly sophisticated, they should be able to easily
download from a link that you email them, or just email them an already
linked front-end. It takes seconds. If they're not at all computer literate,
one of the tools above will do the job.

 

[bcap]

What I do is to write a vbscript file, and put a shortcut to
it on the user's desktop, which launches the application.

There are actually three files involved: the main master (on a file
server), a local master copy, and the local run copy. The process is thus:

Does the local master exist? If not, copy the main master to the local
master.
Is the local master older than the main master? If so, copy the main master
to the local master.
Copy the local master to the local run copy.
Launch the local run copy.

This ensures that (i) users always get a "fresh" front-end when they launch
the system, thereby eliminating problems with corruption and bloat (ii) new
versions get automatically distributed simply by replacing the main master
and (iii) file copies across the network only occur when there is a new
version.

It does have the *dis*advantage that any changes users make to their
environment, where such changes are stored in the FE file itself, are lost
each time they re-start the system - but this is going to happen anyway
whenever you update the front-end.

 

[Peter Hibbs]

As the others have said, splitting the database and having seperate
copies of the front-end on each computer is the only way to go.

If you are likely to want to make changes to the back-end file in the
future you could have a look at my Back End Update Utility code. To
re-link the front-end to the tables in the back-end see the BE Re-Link
code and to update the front-end automatically you could use the Front
End Updater Utiliy. You can find all these at :-

http://www.rogersaccesslibrary.com/...p?FID=21&SID=5debzz2c87c6957859f13b1d2zcccfb4

HTH

Peter Hibbs.

 

[Bobk]

Thanks to all for the response to my problem. It looks like I'm on the right
track by having a copy of the front-end on each work station. At this point I
need to work on automatically updating the front-end at the work stations to
eliminate the hand work. You have all given me some good ideas. Thanks again.