Pros & Cons of sharing a front end MDB (Client workstation vs. Server)

[Max Vit]

I have deployed few Access apps splitting it in Front End and Back
End. Our environment uses Win XP SP2 for clients, Win 2k3 for servers
and Access 2003. The max. number of clients is about 50 (concurrent
users is estimated around 10).

Whilst the Back End always lives on a server, I am not quite clear
where the Front End should live.

I have searched the web and find contradicting views.

Common sense tells me that if I have the Front End in the server then
maintenance should be a breeze because you maintain all your forms,
VBA codes, libraries, options, etc in just one place - but I am not
quite clear about *what* Access features are managed on the server and
*what* are managed (and dependent) on the workstation's install of
Access.

But it *seems* that in a shared environment it is better to have each
client with a copy of the Front End installed at their workstations
because the LDB file that contains the locking information seems to
work better - and this would be high maintenance because there are ~50
clients to maintain.

Is this correct? Will I have less chance of trouble with LDB files if
I have the Front End living on client's workstations as opposed to
having the Front End living on a server and being accessed by multiple
clients?

What would be best practice in a shared environment for a split MDB?
To have the Front End being accessed directly on the server or to
install the Front End on each client's workstation?

[Rick Brandt]

"Max Vit" <mv**@safe-mail.netwrote in message
news:11******** ************@e9 g2000prf.google groups.com...

>I have deployed few Access apps splitting it in Front End and Back
End. Our environment uses Win XP SP2 for clients, Win 2k3 for servers
and Access 2003. The max. number of clients is about 50 (concurrent
users is estimated around 10).

Whilst the Back End always lives on a server, I am not quite clear
where the Front End should live.

I have searched the web and find contradicting views.

Common sense tells me that if I have the Front End in the server then
maintenance should be a breeze because you maintain all your forms,
VBA codes, libraries, options, etc in just one place - but I am not
quite clear about *what* Access features are managed on the server and
*what* are managed (and dependent) on the workstation's install of
Access.

But it *seems* that in a shared environment it is better to have each
client with a copy of the Front End installed at their workstations
because the LDB file that contains the locking information seems to
work better - and this would be high maintenance because there are ~50
clients to maintain.

Is this correct? Will I have less chance of trouble with LDB files if
I have the Front End living on client's workstations as opposed to
having the Front End living on a server and being accessed by multiple
clients?

What would be best practice in a shared environment for a split MDB?
To have the Front End being accessed directly on the server or to
install the Front End on each client's workstation?

In a perfect world the difference would come down to performance and ease of
updates. Individual (local) front ends perform better and a single front end
(might) have some advantages from a version control/update stand-point.

In the real world though we have to add the fact that sharing a single front end
vastly increases the chance of file corruption including corruption of the data
in the back end. This single point means that ALL shared apps should be run
from individual front ends (preferably locally installed).

Beyond that single point is a long list of other advantages that individually
installed front ends has and the fact that the one dubious disadvantage
(updates/version control) is easily solved for individual front ends using any
of a number of auto-update strategies.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Max Vit]

On Jul 16, 12:23 pm, "Rick Brandt" <rickbran...@ho tmail.comwrote:

In the real world though we have to add the fact that sharing a single front end
vastly increases the chance of file corruption including corruption of the data
in the back end. This single point means that ALL shared apps should be run
from individual front ends (preferably locally installed).

Thanks Rick - So what I have read about sharing Access over the WAN
using a thin client (Citrix, Tarantella) or Terminal Servers is not a
wise idea as it relies having a Front End in a single spot being
accessed by multiple clients and thus enhancing corruption chances? Or
am I missing something?

[Larry Linson]

"Max Vit" <mv**@safe-mail.netwrote

Whilst the Back End always lives on a server,
I am not quite clear where the Front End
should live.

I have searched the web and find
contradicting views.

If so, then you have either been visiting different sources than I --
because the strong concensus in posts by clearly-knowledgeable people in the
newsgroups I frequent is "each user gets a copy of the FE".

One of the best Access resources for multiuser issues is Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm. You'll find his AutoFEUpdater
described, and at my site http://accdevel.tripod.com, one of the articles is
on "versioning " which is a slightly different approach to the issue of
keeping users versions up-to-date.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

Max Vit <mv**@safe-mail.netwrote in
news:11******** *************@e 9g2000prf.googl egroups.com:

So what I have read about sharing Access over the WAN
using a thin client (Citrix, Tarantella) or Terminal Servers is
not a wise idea as it relies having a Front End in a single spot
being accessed by multiple clients and thus enhancing corruption
chances? Or am I missing something?

No, each user on a Terminal Server should have their own dedicated
copy of the front end, stored in their user profile.

In other words, just like they would if each user were working from
a workstation.

There are no "pros" so sharing a front end.

There is never any justification for doing so.

It is *always* the wrong thing to do.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Max Vit]

On Jul 16, 1:59 pm, "David W. Fenton" <XXXuse...@dfen ton.com.invalid >
wrote:

No, each user on a Terminal Server should have their own dedicated
copy of the front end, stored in their user profile.

In other words, just like they would if each user were working from
a workstation.

Well, then I was missing something :-)

There are no "pros" so sharing a front end.

There is never any justification for doing so.

It is *always* the wrong thing to do.

Thanks, I like binary replies!

[bobh]

Hi,
I'm sure you'll hear a lot of putting front-ends on servers is a bad
thing and I'm only sharing My experience, all of my Access apps are
split and both the front-end and back-end sit on the server in
different folders and they all work just fine. Some are small(meaning
1-12 users w/ anywhere between 500 - 250,000 records) some are
large(meaning 150+ authorized users w/ 500,000 to 1,000,000 records).
They have good performance and are always are available for use.
The only issue I have ever had is each night our IT dept runs a
process that detaches all pc processes that are still attached to
servers and the one 'got ya' I've come across is a user will go home
and leave there pc logged in with an Access application 'open'. When
the IT process de-attaches the that pc the front-end will corrupt
itself since it was an abnormal termination. So, whenever I implement
an Access app here, during user training I'll kept telling them about
the importance of shutting down access application before they leave
for the day and of course I'm never far away from backups.
On the Citrix side of things, at least here, the front-end sits on the
Citrix server(so it's a common front-end) and the back-end is actually
a SQLServer back-end
Your mileage may verry
bobh.
On Jul 15, 10:36 pm, Max Vit <[e-mail]:

On Jul 16, 12:23 pm, "Rick Brandt" <rickbran...@ho tmail.comwrote:

In the real world though we have to add the fact that sharing a single front end
vastly increases the chance of file corruption including corruption of the data
in the back end. This single point means that ALL shared apps should be run
from individual front ends (preferably locally installed).

Thanks Rick - So what I have read about sharing Access over the WAN
using a thin client (Citrix, Tarantella) or Terminal Servers is not a
wise idea as it relies having a Front End in a single spot being
accessed by multiple clients and thus enhancing corruption chances? Or
am I missing something?

[Tony Toews [MVP]]

"David W. Fenton" <XX*******@dfen ton.com.invalid wrote:

>So what I have read about sharing Access over the WAN
using a thin client (Citrix, Tarantella) or Terminal Servers is
not a wise idea as it relies having a Front End in a single spot
being accessed by multiple clients and thus enhancing corruption
chances? Or am I missing something?

No, each user on a Terminal Server should have their own dedicated
copy of the front end, stored in their user profile.

Stored where in their user profile?

>In other words, just like they would if each user were working from
a workstation.

There are no "pros" so sharing a front end.

There is never any justification for doing so.

It is *always* the wrong thing to do.

Agreed.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[Tony Toews [MVP]]

Max Vit <mv**@safe-mail.netwrote:

>Common sense tells me that if I have the Front End in the server then
maintenance should be a breeze because you maintain all your forms,
VBA codes, libraries, options, etc in just one place -

Not really. Even if you give each user their own copy of the FE MDB/MDE, which is
what you must do, then you would need to kick each user out before you could give
them a new copy of the FE. PITA.

I specifically created the Auto FE Updater utility so that I could make changes to
the FE MDE as often as I wanted and be quite confident that the next time someone
went to run the app that it would pull in the latest version. For more info on the
errors or the Auto FE Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up
to date.

In a Terminal Server or Citrix environment the Auto FE Updater now supports creating
a directory named after the user on a server. Given a choice put the FE on the
Citrix server to reduce network traffic and to avoid having to load objects over the
network which can be somewhat sluggish.

>But it *seems* that in a shared environment it is better to have each
client with a copy of the Front End installed at their workstations
because the LDB file that contains the locking information seems to
work better -

Using a shared copy of the FE risks corrupting the FE. And you might not even be
able to do that as you can get some interestnig messages.

The problems really have nothing to do with the LDB file.

>and this would be high maintenance because there are ~50
clients to maintain.

Not with the Auto FE Updater or similar approach. Once setup you can forget about
all the high maintenance details.

>Is this correct? Will I have less chance of trouble with LDB files if
I have the Front End living on client's workstations as opposed to
having the Front End living on a server and being accessed by multiple
clients?

Very much so. Now you can put each users FE on the file server. But the
performance would likely be slightly slower.

>What would be best practice in a shared environment for a split MDB?
To have the Front End being accessed directly on the server or to
install the Front End on each client's workstation?

Never, ever share a FE MDB/MDE.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[Max Vit]

Hi Tony, Rick, David, Larry & Bob - Thanks the replies; I now know
what to look for!

Hey Tony - Your Auto FE Updater seems what I need, I'll have a try and
let you know.

Thanks again - Max